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ABSTRACT 


This  report  describes  a  cximputer -assisted  methodology  for  solving 
the  Operational  Routing  and  Scheduling  Problem  of  the  Military  Sealift 
Command.     This  is  the  problem  of  assigning  cargoes  to  available  ships  in  an 
emergency  situation  so  that  (a)   cargoes  reach  their  destinations  within 
prescribed  time  limits,    (b)    some  prescribed  system  performance  measure  is 
optimized  and    (c)   other  constraints  are  satisfied.     The  methodology  is 
well-suited  to  an   (eventual)    "expert  system"  approach  to  solving  hard 
combinatorial  problems.     Its  principles  are  most  appropriate  for 
large-scale  dynamic  allocation  problems.     Thus,   the  af^oach  is  modular, 
hierarchical,    interactive,   adaptive  and  evolutionary.     The  computer   program 
implementirg  this  methodology  has  been  specifically  designed  to  handle  the 
special  complexities  of  this  problem,  vrtiile  at  the  same  time  allowing  for 
future  extensions  and  enhancements.     It  decomposes  the  overall  problem  by 
time  and  uses  a  network  flow  algorithms  to  optimally  solve  subproblems  in 
conjunction  with  a  utility  function  that   is  a  function  of  ship  utilization, 
timely  delivery  and  cargoes,   and   port  congestion. 

This  report  critically  assesses  the  structure  and  complexity  of 
this  class  of  problems,  describes  the  proposed  methodology  in  detail,   along 
with  an  evaluation  of   its  advantages  over  alternative  approaches,   presents 
computational  experience  with  the  procedure  and  outlines  current  and  future 
plans  of  this  project. 
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CHAPTER  1 


EXECUTIVE  SUMMARY 


1.1  Introduction:  Project  Objectives 

The  purpose  of  this  report  is  to  describe  research  carried  out  at 
MIT  in  conjunction  with  the  project  "Analysis  and  Solution  Algorithms  of 
Sealift  Routing  and  Scheduling  Problems"    (referred  to  from  now  on  as  "the 
MIT  Sealift  Routing  and  Scheduling  Project",  or  as  "the  Sealift  Project", 
or  simply  as  "the  project") .     This  report  covers  activities  en  the  project 
up  to  May,   1985. 

Progress  in  the  Sealift  Project  to  date  has  been  in  accordance  with 
both  the  scientific  objectives  as  set  forth  in  the  project's  original 
proposal  and  with  the  schedule  that  was  proposed  to  achieve  these 
cfojectives   (Psaraftis  and  Orlin,   1982) .     Specifically,  en  a  short-term 
basis  we  had  proposed  to   (a)    investigate  a  class  of  sealift  routing  and 
scheduling  problems,    (b)   develop,   analyze  and  test  solution  algorithms  for 
such  problems  and    (c)   work  with  the  MSC  and  others  so  as  to  increase  our 
knowledge  of   these  problems.     On  a  longer-term  basis,  we  had  set  forth  the 
following  goals:    (d)   develop  a  procedure  that  could  be  ultimately 
implemented  within  the  scheduling  subsystem  of  the  SEASTRAT  system  of  the 
Military  Sealift  Command    (MSC) ,    (e)    aihance  the  state  of  the  art  in  the 
solution  of  large-scale  scheduling,  distribution,   and  transportation 
problems,  and   (f)    advance  the  state  of  knowledge  in  interactive 
user -friendly  algorithms. 

The  principal  product  for  cur  work  thus  far  is  what  has  been  named 
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the  MIT  Ocean  Routing  and  Scheduling  System, or  MCS^SS.  MC«SS  is  a  computer 
program  that  solves  the  Operational  Routirq  and  Scheduling  Problem  of  the 
MSC,  that  is,  the  problem  of  assigning  cargoes  to  available  ships  in  an 
emergency  situation  so  that  (a)  cargoes  reach  their  destinaticns  within 
prescribed  time  limits,  (b)  some  prescribed  system  performance  measure  is 
optimized  and  (c)  other  constraints  are  satisfied  (details  follow) .  As 
will  be  seen  shortly,  MORSS  possesses  features  that  have  been  specifically 
designed  to  allow  the  handling  of  the  special  complexities  of  this  problem, 
while  at  the  same  time  allowing  for  future  extensions  and  enhancements. 
The  rest  of  this  chapter  summarizes  progress  in  the  project  to 
date,  whereas  details  of  the  work  appear  in  the  remaining  chapters.  We 
begin  by   assessing  the  structure  and  complexity  of  this  class  of 
problems,  an  assessment  which  is  critical  as  to  vn^ich  approach  is  more 
suitable  for  such  prctolems.  We  go  en  to  describe  the  MCRSS  general 
methodology,  along  with  an  evaluation  of  its  advantages  over  alternative 
approaches.  This  chapter  also  briefly  describes  computational  experience 
with  the  MORSS  algorithm,  miscellaneous  other  accomplishments  of  the 
project  to  date,  and  summarizes  current  and  future  plans. 

1.2     Problem  Structure  and  Complexity 

An  early  attempt  was  first  made  hy  the  MIT  team  to  determine  the 
overall  degree  of  complexity  of  the  MSC  Operational  Routing  and  Scheduling 
Problem,  by  relating  its  structure  to  other  routing  and  scheduling  problems 
that  have  been  tackled  in  the  past.  A  timely  assessment  on  this  score  was 
considered  important  in  order  to  guide  subsequent  algorithmic  design 
efforts.  Specifically,  we  wished  to  assess  early  on  in  the  project  v^ether 


there  was  potential  for  either  exact   (optimization)    approaches  or 
optimization -based  heuristics  for  the  solution  of  this   problem.     We  should 
note  here  that  before  this  project  was  initiated  we  had  examined  exact, 
mathematical  programming  formulations  of  several  variants  of  the  general 
MSC  problem  (Bardjis,   1982).     This  vork  examined  several  alternative 
objective  functions,  constraints,  etc.     Nevertheless,  no  further  attempt 
was  made  to  develop  solution  approaches  for  those  formulations,  mainly 
because  of  their  complexity. 

After  a  fair  amount  of  analysis,  we  concluded  that  pursuing  exact 
approaches  for  this  problem  was  not  a  particularly  promising  direction. 
Such  an  assessment  can  be  justified  on  several  grounds.     For   instance,    it 
is  clear  that  a  special   (and  quite  restrictive)   version  of   the  MSC  problem 
is  identical  to  the  multi-vehicle  many-to-many  advance -request  dial-a-ride 
problem.     The  latter   is  the  problem  of  carrying  customers  from  distinct 
origins  to  distinct  destinations  within  specified   pickup  and  delivery  time 
windows.     Such  problems  can  be  considered  as  a  special  case  of  the  MSC 
problem,  the  case  in  which  all  ships  and  cargoes  are  assumed  identical  and 
m  ship/cargo/port  restrictions  exist.     The  difficulty  of  the  dial-a-ride 
problem  can  be  understood  by  the  fact  that  about  15  years  of  research  and 
algorithm  development  for  this  problem  have  resulted  in  essentially  only 
one  class  of  exact  algorithms,  developed  for  the  single -vehicle  problem  and 
viable  only  for  very  small-sized  problems   (Psaraftis,   1980,   1983a) . 

There  have  also  been  several  multi-vehicle  dial-a-ride  algorithms 
developed,  but  all  of  them  are  heuristic.     These  include  the  work  of  groups 
at  the  University  of  Maryland    (Bodin  and  Sexton,   1982),  Georgia  Tech 
(Jarvis  et  al,   1980),  MIT   (Jaw  et  al,   1982,   1984;  Jaw,   1984)    and  others. 
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We  investigated  the  potential  of  "transferring"  to  the  MSC  problem  the 
methodologies  developed  by  these  dial-a-ride  projects.     In  particular,  Jeng 
(1984)    investigated  the  potential  of  developing  a  sequential  insertion 
algorithms  for   the  MSC  using   the  technique  developed  for  dial-a-ride  in  Jaw 
et  al,    (1984),   but  the  resulting  algorithm  was  never   implemented.     We 
finally  decided  gainst  such  adaptations,  mainly  because  of  the  substantial 
algorithm  redesign  that  such  extensicsis  would  involve. 

Another  problem  that  resembles  a  special  case  of  the  MSC  problem  is 
one  analyzed  extensively  by  Fisher  et  al   (1982)   for  the  routing  of  a  fleet 
of  trucks  in  the  chemical  industry.     Their  method  is  based  en  a  heuristic 
that  generates  routes,  a  formulation  as  a  set-packing  problem  and  a 
solution  using  Lagrangian  relaxation.     Our  original  project  proposal 
(Psaraftis  and  Orlin,   1982)    had  suggested  that  ve  investigate  the 
suitability  of  such  an  approach  for   the  MSC  problem.     We  eventually  decided 
not  to  pursue  this  approach  in  our  project  for  several  reasons.     First,  to 
avoid  duplication  of  effort  with  the  peacetime  tanker  scheduling  project 
being  carried  out  by  Fisher  and  his  team  at  the  University  of  Pennsylvania 
(project  also  spcnsored  by  ONR) .     Second,  because  we  thought  that  adapting 
such  an  approach  to  the  MSC  operational  problem  (particularly  to  the 
breakbulk  component  of   it)    would  require   (at  a  minimum)   a  nontrivial  amount 
of  redesign,  most  of  it  heuristic,  to  allow  the  scheduler  to  handle  the 
special  features  of  the  problem,   that  is,  dynamic  updates  of  input  data, 
rolling  horizon,  nonhomogeneous  cargoes,  etc.     In  that  respect,  we  decided 
to  go  ahead  with  a  procedure  that  would  be,  by  design,  tailored  to  the 
dynamic  nature  of  the  MSC  operational  problem. 

We  also  reviewed  the  work  of  Science  Applications  Inc    (SAI,   1982) 
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in  terms  of  suitability  for  the  MSC  operational  problem.     SAI  developed  a 
heuristic  algorithm  for  the  "deliberate  planning"  versicai  of  the  MSC 
problem   ("Scheduling  Algorithm  for  Improving  Lift",  or  SAIL).     We  have 
coxiluded  that  the  SAI  algorithm  would  have  to  undergo  extensive  structural 
modifications  to  be  able  to  functicn  in  an  operational  setting   (see  also 
Chapter  2) .  The  main  reasons  for  such  a  cc«x;lusion  can  be  traced  to  the 
anticipated  difficulty  in  providing  that  procedure  with  the  "restart" 
capability  and  the  appropriate  data  structure  design  that  are  necessary  for 
the  MSC  operational  problem. 

1.3  Solution  Approach:     The  MCE^SS  Algorithm 

The  MSC  operational  problem  is  by  its  nature  too  complex  to  be 
solved  hy  machine  alone.     As  such   it  requires  expert  judgement  as  to  hew  to 
assess  tradeoffs  arri  how  to  schedule  appropriately.     Our  fundamental 
methodology  is  well  suited  to  an   (eventual)    "expert  system"  ajproach  to 
solving  hard  combinatorial  problems.     Thus,  our  focus   is  on  "principles  of 
heuristic  design"  rather  than  on  optimization  techniques  for  special 
classes  of  problems. 

The  principles  that  we  have  focused  on  are  most  appropriate  for 
dynamic  allocation  problems.     As  vge  have  already  discussed  in  a  previous 
progress  report   (Orlin  and  Psaraftis,  1983a)   our  approach  is  modular, 
hierarchical,   interactive,  adaptive  and  evolutionary.     These  generic 
features  -  v*iich  we  consider  essential  for  any  algorithm  that  is  developed 
for  the  MSC  operational  problem  -  are  also  discussed  in  Chapter  3  of  this 
report.  As  a  result  of  these  heuristic  design  principles  and  many  other 
considerations,  we  developed  the  MIT  Ocean  Routing  and  Scheduling  System 
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(MCFSS),  a  general  overview  of  which  goes  as  follows: 

MORSS  operates  on  a  "rolling  horizcn"  basis.     Referring  to  Figure 
1.1,     let  T  be  the  total  duration  of  the  overall  scheduling   process  for  the 
problem  at  hand   (that  is,   from  the  beginning  of  the  process  until  all 
cargoes  have  been  delivered) .     Let  also  a  and  L  be  user  inputs  such  that 
0<a:^  and  OkL<T. 

MCRSS  decomposes  the  overall  problem  by  time,  using  these 
parameters.     At  each  iteration  it  cxily  assigns   (to  ships)   cargoes  whose 
EPT's   (earliest   pickup  times)    fall  within  a  "time  window"  of   (tj^,   t,^  +  L) 
where  t^  is  the  beginning  of  the  window  at  the   (current)    k       iteration  and 
L  the  length  of  the  current  time  window.     Assignments  at  the  k       iteration 
are  initially  made  on  a  tentative  basis,  by  taking  into  account,  amcaig 
other  things,    (permanent)   assignments  already  committed  to  at  previcus 
iterations. 

Once  tentative  assignments  at  the  k       iteration  are  made,  cffily 
those  assigned  cargoes  v^iose  EPT's  are  between  t.    and  t^  +  aL  are  eligible 
for  "permanent  assignment",  v^ich  is  granted  if  they  meet  some  additional 
criteria     (more  details  on  the  assignment/deassignment  procedure  will  be 
givai  shortly) .     All  other  cargoes,  that  is,  all  cargoes  that  have  not  been 
assigned,    plus  all  tentatively  assigned  cargoes  v^ose  EPT's  are  beycxid  t,    + 
aL,  return  to  the  pool  of  unassigned  cargoes  and  are  examined  at  a  future 
iteration.     Once  assignments  at  iteration  k  become  permanent,   the  time 
horizon  is  "rolled"  to  the  interval   (t^^^^,  t,^^^^  +  L),  with  t^^^^  being  the 
earliest  EPT  of  all  yet  unassigned  cargoes.     Note  that  t,    ,  need  not  be 
smaller  than  t^^  +  aL,   but  will  rot  be  greater  than  tj^  +  L   (see  Figure  1.1), 
barring  the  circumstance  of  no  cargoes  having  EPT's  between  t,    ,   and  t.    +  L, 
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ROLLING  HORIZCN 


Figure  1.1 
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One  can  see  that  in  such  a  fashion  there  is  always  an  overlap  between 
two  consecutive  iterations,  and  that  by  considering  all  cargoes  within  a 
time  window  of  length  L  (instead  of  a.L) ,  MORSS  has  a  "lock  ahead" 
capability.  In  that  way,  permanent  assignments  at  the  current  iteration 
take  into  account  information  en  cargoes  that  will  be  handled  in  the 
future.  The  values  of  a  and  L  depend  on  T,  the  cargo  demand  rate  and  other 
inputs,  and  are  subject  to  calibration.  For  a  typical  duration  of  T  =  180 
days,  reasonable  values  for  a  and  L  might  be  a  =  0.5  and  L  =  14  days,  in 
v*iich  case  MORSS  would  "look"  at  two  weeks  of  data  at  a  time  but  would  make 
permanent  assignments  only  one  week  at  a  time. 

Another  concept  central  to  MORSS  is  the  concept  of  "seed" 
assignments.  This  is  a  one-to-one  assignment  of  some  cargoes  (seed 
cargoes)  to  some  ships  (seed  ships)  early  on  in  the  scheduling  process  so 
that  a  good  starting  solution  is  obtained.  Such  a  solution  serves  as  a 
"skeletal"  for  the  final  schedule,  which  gradually  evolves  from  the  seed 
schedule  as  subsequent  assignments  are  made  at  future  iterations.  Seed 
selection  is  performed  by  solvirg  an  assignment  problem  whose  objective 
function  is  the  maximization  of  the  total  "utility"  of  the  assignment.  For 
each  eligible  seed  cargo/ship  pair,  a  special  subroutine  is  called  to 
compute  the  "utility"  of  the  corresponding  pair  (more  on  the  utility 
function  below) .  The  assignment  problem  is  solved  by  using  a  novel  network 
flow  algorithm  developed  by  Orlin  (1983a,  1983b)  for  solving  the 
transportation  problem. 

The  same  network  flow  algorithm  is  used  each  time  a  subsequent 
assignment  is  made,  that  is,  for  every  time  window  of  the  rolling  horizon, 
and  until  the  aid  of  the  horizon.  The  main  differences  between  seed 
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assignments  area  subsequent  assignments  are  (a)  seed  assignments  are  made  on 
a  cne-to-C8ie  basis  v*iereas  in  subsequent  assignments  more  than  cne  cargo 
can  be  simultaneously  assigned  to  a  ship,  and  (b)  subsequent  assignments 
take  into  account  assignments  already  made  at  prior  iterations  by  computing 
not  only   the  utility  of  a  particular  ship/cargo  pair,  but  also  the  change 
in  utility  in  all  previous  cargo  assignments  due  to  the  addition  of  a  new 
cargo  en  a  ship. 

Adding  a  new  cargo  on  a  ship  is  dene  by  inserting  the  origin  and 
destination  of  the  cargo  into  the  current  schedule  of  the  ship.  Tb  avoid 
excessive  computations,  a  simple  heuristic  determines  a  good  pickup 
insertion.  Given  this  insertion,  the  total  change  in  utility  of  the 
schedule  of  the  ship  is  computed  for  each  feasible  delivery  insertion  by 
ccnsidering  the  following  components: 

(a)  The  change  in  total  "delivery  time  utility"  of  all  cargoes  on 
the  ship.  The  delivery  time  utility  of  each  cargo  is  assumed  to  be  a  "bell 
shaped"  decreasing  function  of  the  tardiness  of  that  cargo  (the  tardiness 
being  defined  as  the  delay  of  the  cargo  beyond  its  latest  delivery  time  if 
the  delay  is  positive,  and  zero  otherwise) . 

(b)  The  change  in  "utility  due  to  ship  utilization  and  schedule 
flexibility".  For  each  ship,  such  utility  is  assumed  to  be  a  two 
dimensional  "bell-shaped"  decreasing  function  of  the  ratio  of  the  ship's 
residual  capacity  over  its  nominal  capacity  and  an  increasing  function  of 
the  total  allowable  slack  in  the  ship's  schedule. 

(c)  The  change  in  "port  cesigestion  utility"  due  to  hxith  pickup  and 
delivery.  For  each  port,  such  utility  is  assumed  to  be  a  decreasing 
function  of  the  port's  utilization,  defined  as  the  ratio  of  ships  visiting 
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the  port  over  the  capacity  of  the  port,   in  ships. 

The  final  choice  for  delivery  insertion  is  the  one  that  yields  the 
maximum  overall  utility. 

Figure  1.2     exhibits  the  structure  of  MQRSS.     Only  major  modules  of 
the  procedure  are  shown  and  "blown-up".     Minor  routines,  vihidh  perform 
arithmetic  calculations,   keep  track  of  schedules  and  perform  other  database 
management  functions,  are  not  shown.     Also  not  shown  is  the  way  the  data 
structures  of  this  process  are  organized  and  linked  together.     These  have 
been  organized  in  a  very  robust  cross-reference  system,  using 
list-processing  techniques.     We  believe  that  these  sophisticated  data 
structures  are  an  integral  part  of  our  contribution  to  a  viable  solution 
methodology  for  the  operational  problem  and  serve  a  function  v^ich  is 
crucial  for  the  ability  of  the  scheduler  to  tackle  the  problem  efficiently 
(see  Appendix  A  for  more  details).     The  code  has  been  written  in  PASCAL, 
vi^ich   is  superior   to  FCfE^TRAN   (and  certainly  CCBOL)   with  respect  to  ease  of 
progranming  and  handling  of  data  structures.  Further  details  en  the  M3RSS 
computer  program  can  be  found  in  Ap^ndices  B  and  C. 

MOI^SS  cannot  be  directly  compared  with  procedures  such  as  SEACOP  or 
the  SAI  algorithm,  which  have  been  developed  for  the  deliberate  planning 
(rather  than  the  operational)  MSC  problem.     Nevertheless,  ve  conclude  this 
subsection  with  a  summary  of  ways  by  v*iich  we  feel  MOBSS  has  enhanced  the 
state  of  knowledge  in  solution  tools  for  this  specific  class  of  problems 
and  in  heuristic  design  for  oompiex  problems  in  general: 

(a)  MORSS  provides  a  measure  of  overall  system  performance.     The 
actual  utility  achieved  can  be  measured  against  the  maximum  possible 
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overall  utility. 

(b)  MCf^SS  incorporates  queueing  effects  through  port  congestion 
utility.  A  more  refined  representation  of  queueing  delays  can  be  readily 
incorporated  into  the  cargo  lateness  utility  function  (see  also  Chapter  3). 

(c)  MCX^S  is  flexible.  It  can  handle  practically  any  number  of 
cargoes  per  ship.  Its  hierarchical  and  nodular  structure  allows  it  to 
adapt  easily  to  the  staggered  availability  times  of  different  cargoes  and 
ships.  The  code  is  easily  expandable  and  maintainable,  and  its  design  is 
such  that  it  can  be  easily  "interrupted"  to  allow  for  interaction  with  the 
human  scheduler. 

(d)  MORSS  can  handle  many  problem  complexities  easily.  In  fact, 
the  addition  of  these  may  actually  reduce  subproblem  size  and  overall 
running  time.  Such  complexities  include  the  presence  of  divisible  and 
indivisible  cargoes,  route  restrictions,  cargo/port  or  other  shipping 
constraints,  changes  in  movements  requirements,  etc. 

1.4    Computational  Experience 

We  have  tested  the  MCRSS  algcxithm  with  data  supplied  to  us  by  the 
MSC.  The  MSC  database  includes  information  on  505  cargoes,  232  ships  and 
26  ports. 

Each  of  the  cargoes  is  either  a  single  item  or  a  collection  of 
items  that  have  a  distinct  POE  and  a  distinct  POD.  In  addition,  each  cargo 
has  a  preferred  ship  type,  an  Earliest  Pickup  Time  (EPT) ,  an  Earliest 
Delivery  Time  (EDT) ,  and  a  Latest  Delivery  Time  (LDT) .  Also  known  is  that 
cargo's  Short  Tcxis,  its  Measurement  Tons  and  its  Deck  Area.  The  505 
cargoes  are  classified  into  8  categories,  according  to  preferred  ship  type: 
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These  are  breakbulk  (193  cargoes) ,  seatrain  (13  cargoes) ,  RD/RO  (151 
cargoes) ,  self-sustaining  ocsitainer  (54  cargoes) ,  tanker  (45  cargoes) ,  and 
barge  carrier  (25  cargoes)  while  4  cargoes  have  an  unspecified  ship 
preference. 

Ships  are  classified  into  3  fleet  types  and  6  ship  types:  The 
fleet  type  codes  are  MSC  controlled  (38  ships) ,  Ready  reserve  (38  ships) 
and  Sealift  Readiness  Prograjii  (156  ships) .   The  ship  type  codes  are 
breakbulk  (100  ships),  seatrain  (5  ships),  RD/RO  (5  ships),  self-sustaining 
container  (9  ships),  tanker  (25  ships)  and  barge  carrier  (18  ships). 
Information  on  ships  ircludes  capacity  (weight/volume/deck  area),  draft, 
speed,  cargo  loading  and  unloading  rates,  as  well  as  initial  location. 

Finally,  the  26  ports  of  the  MSC  database  are  classified  as 
follows:  12  are  POE's,  5  are  PCXD's,  and  the  remaining  9  are  both  POE's  and 
PCD's.  All  ports  of  the  database  are  located  in  the  United  States,  the 
Panama  Canal  zone  and  the  Pacific.  Information  on  ports  includes  the 
throughput  characteristics  of  their  various  berths  and  terminals.  All 
inter -port  distances  are  also  known. 

Given  a  particular  "problem  instance"  (that  is,  a  set  of  prescribed 
inputs  for  the  MSC  operational  problem) ,  we  have  assumed  that  the  scheduler 
would  like  to  obtain  a  preliminary  idea  regarding  whether  available 
resources  are  enough  to  satisfy  the  prescribed  cargo  movement  requirements. 
If  the  opposite  turns  out  to  be  the  case,  it  would  make  little  sense  to 
proceed  with  a  detailed  scheduling  run,  because  most  cargoes  would  be 
delivered  late.  Instead,  it  would  then  make  sense  to  relay  infeasibility 
information  immediately  to  the  chain  of  command  "upstream",  so  that  either 
the  cargo  movement  requirements  are  modified,  or  additional  resources  are 
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made  available,  or  sone  other  measure  is  taken  to  alleviate  this  problem. 

Gross  feasibility  analysis  can  he   performed  at  various  levels  of 
detail.  At  the  simplest  level,  one  can  check  whether  the  prescribed  cargo 
delivery  time  requirements  alone  are  reasonable  or  unreasonable.  Such  a 
test  calculates  the  maximum  time  slack  between  each  cargo's  actual  delivery 
time  and  its  LOT  under  the  optimistic  assumption  that  the  cargo  leaves  its 
PCE  immediately  at  its  EPT  and  travels  directly  to  its  PCD.     The  same  test 
also  calculates  the  minimum  ship  speed  required  if  the  cargo  leaves  its  PQE 
promptly,  is  delivered  to  its  VCD   at  its  LOT  and  travels  directly. 

Applying  such  a  test  to  all  193  cargoes  belonging  to  the  breakbulk 
category  shewed  that  delivering  all  of  these  cargoes  en  time  is  virtually 
impossible,  irrespective  of  both  actual  ship  resources  and  scheduling 
strategy.  Similar  observations  were  made  in  the  MSC  database  on  virtually 
all  other  cargo/ship  categories.  From  our  discussicns  with  MSC  personnel, 
we  understood  that  such  infeasibility  of  the  database  could  be  attributed 
in  part  to  the  "sanitizaticn"  process  that  was  used  to  convert  the  database 
from  classified  to  unclassified.  Other  factors  might  be  valid  as  well, 
sudi  as  the  facts  that  in  practice  a  cargo's  EPT  and  IDT  are  sometimes  (if 
not  always)  determined  by  two  different  (and  sometimes  unrelated)  decision 
processes.  As  a  result,  a  cargo's  liDT  usually  reflects  neither  that 
cargo's  availability  at  its  PCE,  nor  its  PQE/P(X)  distance. 

A  second -level  feasibility  test  takes  also  into  account  ship 
resources  as  well.  It  formulates  the  feasibility  problem  as  a 
"transportaticxi"  problem.  It  sets  up  a  bipartite  network,  with  supply 
nodes  representing  ships,  and  demand  nodes  representing  cargoes.  The 
optimal  value  of  this  problem  is  a  lower  bound  en  the  actual  total  weighted 
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tardiness  (ten-days  late)  that  would  incur  under  any  actual  allocaticn  of 
available  ship  to  cargoes. 

We  chose  a  subset  of  the  MSC  database  for  the  initial  runs  of  MCKSS 
with  certain  goals  in  mind.  For  ease  of  analysis  we  wanted  ships  and 
cargoes  to  be  of  compatible  types.  We  desired  the  problem  size  to  be  at 
once  small  enough  to  easily  manage  and  comprehend,  and  large  enough  to 
contain  the  oomplexities  of  the  MSC  operational  sealift  problem.  Finally, 
we  wanted  a  nontrivial  problem,  one  which  reflected  to  some  extent  the 
infeasibility  of  some  of  the  time  windows  in  the  MSC  database. 

Our  objective  in  the  initial  comnpatational  study  was  twofold. 
First,  we  wanted  to  verify  that  NDRSS  was  operating  correctly  and  in  a 
manner  consistent  witli  its  design.  Secondly,  vie   desired  to  begin 
calibration  of  the  parameters  of  the  model,  that  is,  empirically  test  the 
effect  of  seed  assignments,  cargo  size  and  time  window  arrangement  en  the 
quality  of  the  overall  solution.  Our  procedure  was  also  two-fold.  First, 
we  tested  MORSS  on  increasingly  larger  problems  until  we  were  satisfied 
that  the  model  was  debugged.  Then  we  began  the  calibration  study,  which  we 
now  discuss. 

The  initial  runs  confirmed  our  intuition  that  seed  assignments 
greatly  influence  the  quality  of  the  final  schedule.  Our  strategy  was  to 
try  a  variety  of  seed  assignments  in  order  to  gain  a  measure  of  the 
quantitative  effects  of  this  key  factor.  These  assignments  were  made 
randomly  at  first,  then  varied  to  test  various  hypotheses  about  what 
constitutes  "good"  seed  assignments.  In  particular,  ve  attempted  to 
improve  the  quality  of  the  solution  (e.g.  decrease  the  number  of 
undelivered  cargoes)  by  modifying  the  assignment  of  seeds  from  one  run  to 
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the  next. 

From  the  runs  of  MDRSS,    (see  details  in  Chapter  4),    it  became 
evident  that  the  performance  of  the  system  depends  highly  en  the  particular 
data  set  being  used.     Many  factors  are  involved.     Boundary  conditions, 
cargo  size,   seed  selection  and  interactions  betrween  large  cargoes  may 
account  for  much  of  the  difficulty.     In  addition,   the  parameters  involved 
in  the  utility  functions  need  detailed  calibration  themselves,     lb  aid  in 
the  analysis  of  the  run,  MCE^SS  computes  a  large  variety  of  statistics  at 
the  end  of  each  run.     These  statistics  are  the  measures  hy  which  we 
evaluated  the  performance  of  the  system.       The  most  important  of  the  cargo 
statistics  are  the  percentages  of  cargoes  (delivered)   on  time  and  tons 
(delivered)   on  time.     These  most  clearly  reflect  the  priinary  concern  of  the 
MSC  to  deliver  cargoes  on  time. 

Among  the  ship-related  statistics,   route  circuity,  ship  utilization 
and  percent  of  time  spent  in  port  are  the  most  important.     By  "route 
circuity"  we  mean  the  ratio  of  the  total  distance  traveled  by  a  ship 
divided  by  the  sum  of  POE-PCO  distances  for  all  cargoes  carried  fcy  the 
ship.     Thus,  a  low  circuity   (less  than  half)   means  the  ship  carries  many 
cargoes  most  of  the  time,  while  a  high  circuity   (more  than  1.5)   means  the 
ship  carries  few  cargoes  at  a  time,  and  takes  a  rather  circuitous  route, 

probably  deadheading  a  good  part  of  the  time  also.     These  measures  are 
important  as  indications  of  the  efficiency  at  v^ich  the  system  operates. 

Results  of  these  runs  show  that  ship  utilization  and  the 
percentage    of  tons  delivered  are  not  correlated  with  the  percentage  of 
tens  delivered  on  time.     They  also  show  a  strong  linear  correlation  between 
the  percentage  of  on-time  cargoes  and  tons.     The  percentage    of  cargoes  on 
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time  seems  close  to  being  independent  of  the  percentage  delivered.  These 
preliminary  results  indicate  that  ship  utilization  is  not  a  good 
performance  measure  for  problems  with  tight  or  infeasible  scheduling 
requirements.  This  result  will  be  checked  more  closely  with  a  larger 
feasible  set  of  cargo  movement  requirements  during  the  calibration 
procedure . 

In  general,  our  initial  MPPSS  runs  appear  to  be  interesting  and 
encouraging.  The  algorithm  generates  schedule  patterns  that  seem  to  be 
"clever"  with  respect  to  a  particular  cargo  movement  requirement.  For 
instance,  roundtrips  or  other,  more  complicated  routes  are  generated,  and 
large-scale  cargoes  are  split.  Further  inter pretaticsn  of  these  and  other 
test  runs  would  feed  back  into  further  refining  the  algorithm. 
1.5     Miscellaneous  Other  Activities 

Other  than  the  developnent  of  MORSS,  there  have  been  a  number  of 
other  activities  related  to  the  project: 

(1)  We  have  had  four  meetings  with  MSC  personnel:  One  in 
Washington,  D.C.  in  May  of  1983  where  a  general  discussion  (which  included 
the  University  of  Pennsylvania  team)  was  conducted,  and  three  at  MIT,  in 
December  of  1983,  in  November  of  1984  and  in  May  of  1985,  v^ere 
representatives  of  the  MSC  interacted  with  the  MIT  team  on  topics  related 
to  the  algorithm  and  the  MSC  database.  The  last  two  meetings  included 
computer  demcxistraticais  ty  the  MIT  team  of  versicxis  of  the  MORSS  algorithm. 

(2)  In  March  of  1984  the  MIT  team  presented  its  work  at  a  workshop 
organized  by  the  MSC  and  the  Joint  Deployment  Agency,  in  Tampa,  Florida. 
The  workshop  included  presentations  by  the  University  of  Pennsylvania  and 
Georgia  Tech  groups  (see  also  Jarvis,  et  al,  1982)  en  their  pojects. 
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(3)  Progress  in  the  project  has  been  also  presented  at  three 
ORSA/TIMS  meetings:     One  in  Orlando   (Orlin  and  Psaraftis,   1983b),   cxie  in 
San  Francisco   (Orlin  and  Psaraftis,   1984),   and  one  in  Bostcai   (Psaraftis  et 
al,  1985). 

(4)  A  student  M.Sc.  thesis  was  written  on  the  solution  of  a  version 
of  the  MSC  prctolem  using  an  insert i<xi  algorithm  (Jeng,   1984). 

(5)  A  PhD  thesis  was  submitted  oi  the  development  and  analysis  of 
certain  algorithms,  exact  and  heuristic,   for  "analyzable"  version  of  the 
MSC  problem   (Kim,   1985) .     A  paper  based  oi  this  work  was  presented  at  the 
EURO-VIII  Ccaiference  in  Bologna,   Italy   (Kim  et  al,   1985). 

(6)  An  annotated  bibliography  of  about  70  references  in  this 
general  problem  area  was  prepared   (Thompson,   1983) .     These  references  are 
maintained  in  the  MIT  project  library. 

(7)  Finally,  contacts  have  been  maintained  with  a  sister  project, 
spcnsored  by  the  Military  Airlift  Command    (MAC),   at  MIT's  Flight 
Transportation  Laboratory.     Although  the  scheduling  problems  of  MSC  and  MAC 
and  the  scopes  of  the  two  projects  are  different,  both  sides  are  interested 
in  exploring  the  potential  for  transferring  scheduling  methodologies  from 
one  project  to  the  other. 

1.6  Current  and  Future  Plans 

Further  research  directicxis  oitail  six  tasks:      (1)    investigate  and 
calibrate  alternative  utility  functicxis,      (2)    investigate  cargo  assignment 
interactions,      (3)   develop  more  sophisticated  seed  selection  methods,    (4) 
model  queueing  effects  at  ports,      (5)     undertake  sensitivity  analysis  and 
(6)   further  test  the  algorithm  and  enhance  its  user-friendly  features.     At 
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the  time  of  the  writing  of  this  report,  the  MIT  team  is  concentrating  on 
tasks  (1)  and  (6),  all  other  tasks  being  left  for  a  future  phase  of  the 
project.   A  detailed  description  of  these  tasks  is  givoi  in  Chapter  5. 
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CHAPTER  2 


BACKGROUND  ON  THE  PRCBLEM 


2.1    Introduction 

Before  one  can  attempt  to  solve  a  problem,  cne  must  first  define 
it.  lb  that  end,  the  MIT  project  team  has  spent  a  considerable  amount  of 
effort  in  the  early  phases  of  the  project  in  order  to  better  understand  the 
structure  and  complexity  of  the  problem  at  hand.  A  second,  parallel  effort 
ccHTcerned  the  definition  of  "the  problem"  in  clear  and  explicit  rather  than 
vague  or  ambiguous  terms. 

As  in  many  complex  problems,  ambiguity  in  the  MSC  problem  ranges 
from  issues  related  to  lack  of  a  clear  definition  of  the  problem 
objective(s)  ca:  constraints,  to  issues  such  as  v^iether  a  specific  problem 
parameter  must  be  ccxisidered  a  decision  variable  or  an  exogenous  user 
input.  To  state  a  few  examples,  issues  that  have  to  be  addressed  to 
resolve  ambiguity  irclude  (but  are  not  limited  to)  the  following:  Does  the 
MSC  wish  to  maximize  the  number  of  cargoes  delivered  an   time,  or  minimize 
the  total  ten -days  of  cargo  delivered  late?  Does  one  allow  a  cargo  to  be 
split?  Does  one  consider  dae  dates  as  "soft"  or  as  "hard"  constraints? 
Does  one,  in  fact,  consider  due  dates  as  decision  variables  in  this 
problem,  or  does  one  take  them  as  exogenous  user  inputs?  (With  respect  to 
this  last  issue,  it  is  clear  that  somebody  in  the  v^ole  chain  of  command  in 
sealift  scheduling  somehow  makes  a  decision  regarding  what  the  due  date  of 
a  cargo  should  be;  so  the  question  is  whether  this  decision  is  part  of  our 
problem) .  Does  one  similarly  consider  ports  of  embarkation  or  debarkation 
as  decision  variables,  or  take  them  again  as  exogenous  user  inputs?  It  is 
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clear  that  the  resolution  of  such  ambiguities  is  parainount  in  our  ability 
to  create  a  realistic  model  for  the  real -world  problem  and  ultimately  solve 
the  problem. 

Both  efforts  described  above  (that  is,  complexity  assessment  and 
problem  definition)  were  undertaken  in  parallel  because  we  wished  to  come 
up  with  a  problem  definition  that  was  both  realistic  and  at  the  same  time 
well -understood  in  terms  of  structure  and  complexity.  We  paid  particular 
attention  to  the  identification  of  similarities  t)etween  the  problem  at 
hand  and  other  problems  that  were  tackled  in  the  past,  so  that  we  could 
take  maximum  advantage  of  known  techniques  that  might  be  transferred  to 
this  problem. 

The  purpose  of  this  chapter  is  to  describe  the  results  of  our 
assessment  on  that  score,  and,  in  a  way,  put  the  problem  at  hand  into  the 
proper  perspective.  Such  a  perspective  forms  the  basis  of  the  development 
of  the  MORSS  soluticn  procedure  that  will  be  described  in  Chapter  3.  An 
overview  of  the  real-world  problem  and  current  practices  is  presented  in 
Section  2.2.  Section  2.3  reviews  similarities  and  differences  between  this 
problem  and  other  related  problems  and  explores  the  possibilities  of 
methodology  transfer  among  these  problems.  Section  2.3  specifies  the 
version  of  the  problem  to  be  examined  and  distinguishes  between  parameters 
that  are  explicit  decision  variables  in  this  analysis,  and  other  variables, 
which  are  exogenous  user  inputs  for  the  version  of  the  problem  at  hand. 
Finally,  Section  2.5  sets  forth  a  set  of  generic  design  features  that  a 
computer -assisted  procedure  should  possess  in  carder  to  be  able  to  solve  the 
MSC  operational  problem,  and  comments  en  the  suitability  of  the  SAI 
algorithm  for  solving  that  problem. 
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2.1  Overview  of  the  Real -World  Prcfelem  and  Current  Practices 

The  Military  Sealift  Command   (MSC)    is  the  agency  respcaisible  for 
providing   aealift  capability  for  the  Department  of  Defense.     Three  of  its 
nost  important  missions  according   to  Scott   (1982)    are  the  following: 

(1)  Provide  peacetime  logistical  sealift  support  of  military 
forces  worldwide; 

(2)  Develop  plans  for  the  expansion  of  the  peacetime  sealift  fleet 
to  support  military  contingency  operaticns  and  mobilization.     And 

(3)  Acquire  and  operate  this  expanded  fleet  to  provide  contingency 
and  mobilization  sealift  support  of  military  forces  worldwide. 

The  MSC  scheduling  activities  in  support  of  peacetime  logistical 
suf^rt  are  similar  to  those  accomplished  by  commercial  liner  companies  and 
by  chartered  shipping  operators.     The  problem  is  to  size  the  fleet  at  the 
optimum  level  and  to  schedule  ships  to  transport  cargoes  among  ports  most 
economically. 

The  scheduling  requirements  for  the  MSC  contingoicy  and 
mobilization  mission  areas  are  different  fron  those  during  peacetime 
operations.     Besides  involving  a  larger  number  of  ships  and  cargoes,    (this 
number  can  be  as  high  as  several  thousand  cargoes  and  1,500  ships)   the 
ability  to  deliver  cargo  en  time  new  becomes  paramount.     Under  such  a 
setting,   the  objective  of  the  MSC  is  to  ensure  that  all  cargo,  dry  and 
liquid,  arrive  at  destination  as  planned. 

The  key  objective  of  MSC's  strategic  planning  of  sealift  operatiens 
for  contingency  and  mobilization  situations  is  to  move  military  forces  and 
supplies  to  the  required  locatien  during  a  period  of  potential  or  actual 
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ccaiflict  within  a  required  time.     For  this  reason,  MSC  has  initiated  the 
development  of  a  comprehensive  methodology,  SEASTRAT,   to  perform  the 
scheduling  of  MSC  transportation  resources  and  therety  evaluate  the 
feasibility  of  meeting  mobilization  requirements.     At  present,     SEASTRAT  is 
intended  to  assist  planners  solve         the  "deliberate  planning"  version  of 
the  MSC  routing  and  scheduling  problem.     This  deliberate  planning  problem 
significantly  differs       from  the  MSC  "operational"  scheduling  problem, 
which   is  the  problem  on  which  the  MIT  project  has  focused. 

Before  we  proceed  with  SEASTRAT,   we  highlight  the  similarities  and 
differences  between  these  two  classes  of  problems: 

Both  the  deliberate  planning  problem  and  the  operational  scheduling 
problem  call  for  an  assignment  of  cargoes  to  ships  so  as  to  satisfy  "as 
best  as  possible"  the  cargo  movement  requirements  and  the  due  dates  that 
have  been  specified  as  part  of  an  "Operational  Plan".  In  the  deliberate 
planning  problem,  inputs  are  generated  accordir^  to  a  plausible  scenario 
that  represents  a  contingency  that  may  arise  in  a  part  of  the  world.  In 
the  operational  problem,  inputs  correspond  to  a  real  scenario  that  has 
actually  occurred  and  evolves  in  time. 

Despite  their  conceptual  similarities  (e.g.  both  problems 
essentially  call  for  a  "reasonable,"  "good,"  or  "optimal"  allocation  of 
cargoes  on  ships  to  satisfy  the  due  dates  that  have  been  specified),  the 
two  problems  have  significant  differences:     For  instance,  the  emphasis  in 
the  deliberate  planning  problem  places  more  emphasis  on  the  determination 
of  the  minimum  number  of  ships  that  are  necessary  for  the  successful 
execution  of  a  plan,  while  the  operational  problem  emphasizes  the  efficient 
use  of  available  ships  to  meet  the  due  dates  with  the  minimum  amount  of 
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delay.     The  deliberate  planning   problem  involves  relatively  long  time 
horizons   (and  thus  involves  a  greater  degree  of  uncertainty;   initial  ship 
positions,  queueirq  delays  at  ports,   and  other  factors  are  either  not  known 
with  certainty  or  cannot  be  predicted  with  accuracy)  v*iile  the  operational 
problem  is  typically  of  shorter  duration  (and  thus  involves  a  lower  degree 
of  uncertainty;  most  of  the  inputs  are  either  known  a  priori  -  e.g. 
positions  or  availabilities  of  ships,  or  become  eventually  known  to  the 
dec is ion -maker  along  the  course  of  events) .     Information  in  a  deliberate 
planning  problem  is  typically  highly  aggregate,  v^ile  in  an  operational 
problem  one  is  typically  faced  with  highly  detailed  information  en  the 
problem.     Several  other  differences  exist,  the  enumeration  of  vrtiich  is 
outside  the  scope  of  this  report.     In  our  opinicai,   the  most  significant 
conceptual  difference  t)etween  the  twD  prctolems  is  as  follows.     Whereas  the 
data  to  the  deliberate  planning   problem  is  specified  in  advance  and  is 
static,   the  input  data  of  the  operational  problem  changes  dynamically  in 
time,  with  the  word  "dynamically"  interpreted  as  "at  the  same  time  the 
dec is ion -making  process   (whether  automated,  manual,  or  man-machine)   is 
taking   piace".     For  instance,  new  cargo  requirements  may  be  imposed  a  week 
after  the  occurrence  of  the  scenario,   that  is,   after  the  initial 
cargo-to-ship  allocation  decisions  have  been  made.     Or,  certain  ships 
and/or  ports  may  cease  to  become  operaticaial  for  various  reasons 
(malfunction,  attrition,  etc).     Many  other  examples  can  be  devised.     It  is 
therefore  clear  that  special  consideration  should  be  given  to  the 
scheduling  methodology  that  "solves"  the  operational  problem,   so  that  its 
dynamic  nature  is  taken  into  account.     Similarly,  extreme  caution  should  be 
exercised  in  attempting  to  "transfer"  to  the  operational  problem 
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metha3olog ies  that  have  beoi  developed  to  solve  the  deliberate  planning 
problem  (more  oi  this  point  later) . 

With  these  considerations  in  mind,  we  come  back  to  SEASTRAT  and 
describe  how  it  relates  to  current  ^BC  practices.  The  objective  of 
SEASTRAT  is  to  schedule  ships  and  cargo  transport  so  as  to  deliver  cargo  to 
the  required  ports  of  debarkation  within  the  proper  time  (see  SEASTRAT, 
1981) .  The  ship  routes  ard  schedules  must  be  consistent  with  initial  cargo 
and  ship  locations,  port  capacities,  cargo  and  ship  types  so  as  to  provide 
a  feasible  (ard  hopefully  "optimal")  solution  to  the  scheduling  problem. 

SEASTRAT  will  eventually  replace  the  Strategic  Sealift  Contingency 
Planning  (SEACOP)  system.  SEACOP  is,  by  today's  standards,  a  rather  old 
system,  run  for  the  first  time  on  MSC's  Hone^AAell  1200  computer  in  1972.  It 
was  designed  bD  perform  detailed  planning.  It  takes  into  account  precise 
ship  characteristic  data  (e.g.  exact  speed,  capacity,  etc.)  and  produces  a 
detailed  shipping  schedule.  SEACOP  was  not  readily  accepted  by  the 
planning  community,  which  was  at  that  time  oriented  to  gross  feasibility 
planning.  The  planning  philosophy  has  since  changed,  and  the  detailed 
output  of  SEACOP  correspcnds  to  current  requirements.  However,  there  are  a 
number  of  deficiencies  in  the  system  that  cause  problems.  The  operaticn  of 
the  system  ocnsumes  considerable  computer  time  (up  bo  forty  hours  for  large 
plans) ;  there  is  no  restart  capability;  the  loading  and  scheduling 
algorithms  lack  credibility.  There  is  also  a  recognized  need  for  an 
automated  trans por tat icn  planning,  v^ich  is  not  provided  by  SEACOP. 

According  to  Kaskin  (1981)  most  of  the  problems  that  analysts  have 
discovered  about  SEACOP  are  due  to  deficiencies  in  the  logic  within  the 
Schedular  Subsystem.  There  are  also  several  other  problems  that  are  the 
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result  of  defects  in  the  overall  system  design  and  implementation. 

When  a  Commander-in-Chief  develops  an  Operational  Plan,  he  also 
establishes  a  Time -Phased  Force  Deployment  Data  (TPFDD)  file  (see  SEASTRAT, 
1981) .  The  file  contains  information  about  v*iat  cargo  is  to  be  transported 
fron  what  p^rt  of  embarkation  to  what  port  of  debarkation,  with  earliest 
and  latest  arrival  dates  specified. 

Currently  the  MSC  processes  the  TPFDD  by  means  of  the  SEACOP 
system.  The  TPFCO  is  edited  for  validity  of  data,  and  movement 
requirements  are  aggregated  en  the  basis  of  commcn  cargo  type,  ports,  and 
time  requironer.ts.  The  system  then  calculates  ship  availability  by  taking 
into  account  the  level  of  mobilization,  determinir^  what  ships  are  usable 
under  that  level  (e.g.  owned  fleet,  available  at  all  times;  NATO  fleet, 
available  only  in  NATO  plans;  etc),  and  calculating  the  time  required  to 
travel  to  various  ports  and  discharge  their  cargo.  Feasibility  is  then 
assessed  by  simulating  the  loading  of  ships  and  the  transport  of  goods,  and 
then  determining  v*iich  loads  were  not  scheduled  or  arrived  later. 

Under  the  present  system,  the  automated  feasibility  analysis  must 
be  improved  by  hand  manipulation  (see  SEASIRAT,  1981).  For  example,  one  of 
SEACOP's  deficiencies  is  that  it  can  only  load  ten  aggregated  cargoes  onto 
a  ship,  no  matter  how  small  the  resulting  load  is.  It  is  therefore  obvious 
that  a  process  of  hand -scheduling  cargo  into  the  empty  space  or  underloaded 
ships  may  shew  a  plan  to  be  more  nearly  feasible  than  the  model  has 
indicated.  Some  analysts  try  to  improve  the  detailed  schedules  produced  by 
SEAOOP  by  hand -rescheduling  or  by  proposing  changes  in  times  associated 
with  specific  loads.  However,  this  approach  becomes  impractical  with  large 
plans.  Other  analysts  make  a  broader  set  of  suggestions  about  relocation 
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or  rescheduling  of  cargoes,  after  looking  at  summary  information  output  by 
the  model  (number  of  shiploads  per  port,  etc.).  An  analyst  can  prepare 
specific  changes  to  the  TPFDD  and  run  SEACOP  again  to  check  feasibility  of 
the  modified  transportation  requirements.  However,  due  tx)  the  SEACCP's 
inefficiency  (up  to  forty  hours  required  for  large  plans) ,  any  process  of 
successive  approximation  to  a  feasible  plan  is  severely  limited. 

A  more  accurate  and  more  efficient  method  for  conducting 
feasibility  analysis  is  needed  to  be  employed  by  SEASTRAT.  This  method 
must  be  able  to  identify  which  requirements  result  in  infeasibility.  In 
this  way,  changes  that  would  render  a  plan  feasible  could  he   suggested. 
Such  changes  could  include  changing  the  level  of  mobilization,  increasing 
shipping  capacity  in  specified  ways,  suggesting  a  better  distribution  of 
cargoes  among  ports  of  embarkation,  etc.  If  this  method  for  suggesting 
changes  involves  successive  approximations  (a  repeated  sequence  of 
adjusting  the  TPFDD  and  performing  feasibility  analysis) ,  thai  the 
feasibility  analysis  must  be  a  quick  process  that  can  be  repeated  several 
times  without  affecting  the  overall  analysis  schedule. 

Unfortunately,  the  schedules  produced  by  SEACQP  are  not  realistic. 
According  to  Kaskin  (1981)  "too  many  ships  with  less  than  50%  utilization 
deliver  their  cargoes  late."  This  pcor  performance  has  to  do  with  the 
design  of  SEACOP 's  Schedular  Subsystem,  as  we  shall  see  belcw.  The 
Schedular  assigns  a  cargo  movement  requirement  from  the  TPFEO  file  and 
scores  each  ship  eligible  to  carry  the  requirement  to  the  port  of 
debarkation,  by  using  a  simple  formula.   (An  eligible  ship  is  one  that 
meets  the  port  of  debarkation  draft  and  length  restrict icxis,  that  has 
sufficient  boom  capacity,  and  that  will  allow  the  ship  to  meet  its  latest 
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arrival  date).     The  score  of  each  eligible  ship  depends  en  the  ship's 
expected  arrival  date  to  the  pDrt  of  debarkation  and  on  the  ship's 
utilization  factor   (i.e.,  capacity  of  ship  utilized  as  a  fraction  of  ship's 
total  capacity).     The  eligible  ship  with  the  Icwest  score  is  assigned  the 
cargo. 

SEACDP's  scoring  formula  does  not  schedule  ships  against  movement 
requirements  in  a  realistic  manner.     It  determines  the  fate  of  a  ship  upon 
assignment  of  its  first  cargo  without  considering  other  available  cargoes. 
Additionally,   if  a  cargo  is  assigned  to  a  ship  that  does  not,  after  all 
cargo  movement  requirements  are  considered,  have  sufficient  cargo  to  be 
commited  to  sail,   then  such  cargo  is  not  sent.     In  reality,  one  could 
possibly  reassign     the  cargo  to  another  ship  that  might  arrive  a  little 
late.     Another  flaw,  mentioned  already,   is  that  the  Schedular  currently 
does  not  allow  more  than  ten  movement  requirements  to  be  assigned  to  the 
same  ship.     Since  movement  requirements  are  oftoi  small  in  size,   t&n  loads 
may  not  be  enough  to  fill  the  ship  above  the  minimum  required  for  that  ship 
to  sail.     Thus,   the  cargo  will  become  "frustrated". 

Kaskin  in  his  Point  Paper  concerning  suggesticais  for  SEACOP's 
improvement  (Kaskin,   1981)    states  the  following: 

"The  overall  result  of  the  above  deficiencies  is  that  SEACOP  produces 
unacceptable  schedules  for  most  plans.     This  can  be  verified  by 
talking  with  the  analysts  who  use  the  model  daily.       Unfortunately, 
there  is  presently  no  way  to  determine  how  poor  the  SEACOP  schedules 
really  are.     SEACDP  has  never  been  validated.     That  is,  SEACDP's 
outputs  have  never  been  compared  with  the  best  schedule  that  human 
operators  might  come  up  with,  given  the  same  ships  and  movement 


-33- 


requirements". 

To  c3ate,  the  most  significant  algorithmic  developnent  effort  in 
conjunction  with  SEASTRAT  (that  is,  with  the  cJeliberate  planning  version  of 
the  problem)  has  been  the  work  of  Science  Applications,  Inc.  (SAI,  1982). 
SAI  developed  an  algorithm  called  "Scheduling  Algorithm  for  Improving  Lift" 
(SAIL). 

SAI  formulated  a  transpDrtaticsn  network  model  to  solve  the 
deliberate  planning  problem.  The  model  was  designed  to  minimize  total 
system  costs  (the  cost  of  the  ship  use  and  penalties  for  lateness  of  cargo 
delivery  represented  as  a  function  of  the  cargo/ship  assignments)  subject 
to  constraints  which  required  that  all  cargo  be  delivered  and  ship  capacity 
not  be  exceeded.  The  objective  function  coefficients  incorporated  all 
system  costs,  including  those  of  delays.  Then  the  problem  was  solved  by 
successive  iterations  over  the  values  of  those  coefficients,  using  a 
well-known  solution  algorithm  for  the  transportation  problem,  until  no 
further  improvement  could  be  made.  Throughout  the  procedure,  time 
constraints  were  regarded  as  being  "soft".   (If  a  time  window  can  be 
violated,  it  is  referred  to  as  a  "soft"  time  ccsistraint) .  The  method  of 
updating  cost  coefficients  and  assigning  seed  cargoes  was  also  heuristic. 

A  detailed  description  of  the  SAI  methodology  is  beyond  the  scope 
of  this  report  and  can  be  found  in  SAI  (1982).  However,  a  crucial  question 
that  the  MIT  team  felt  obliged  to  answer  was  to  what  extent  the  SAI 
methodology,  vrtiich  was  developed  for  the  deliberate  planning  problem,  could 
be  "transferred"  to  the  operational  problem.  This  report  addresses  this 
very  important  issue  in  Section  2.5. 

We  conclude  this  section  by  noting  that  to  date,  there  has  beei  no 
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ccxinterpart  of  SEACOP  or  the  SAI  algorithm  for  the  operational  MSC  problem. 
Thus,   if  an  actual  mobilization  situation  were  to  occur,  detailed  sealift 
scheduling  would  have  to  be  done  by  hand. 

2.3  Relationship  to  Other  Problems 

To  gain  further  insight  into  the  structure  of  the  MSC  problem,  we 
new  review  some  problems  in  other  environments  that  are  coiceptually 
related  to  this  problem,   and  thus,  conceivably  are  promising  from  a 
methodological  viewpoint. 

(1)     The  Dial-A-Ride  Problem 

The  dial -a -ride  problem  is  the  problem  of  carrying  customers  from 
distinct  origins  to  distinct  destinations  within  specified  pickup  and 
delivery  time  windows.     The  problem  can  be  ccnsidered  as  a  restricted 
version  of  the  MSC  problem,   in  which  all  ships  and  cargoes  are  assumed 
identical  and  no  ship/cargo/port  restrictions  exist.     Whereas  it  is  clear 
that  such  a  restriction  is  unrealistic,  we  outline  telcw  the  main 
algorithmic  developments  with  respect  to  dial-a-ride  over  the  past  decade. 

Several  approaches  have  been  developed  for  solving  versions  of  the 
dial-a-ride  problem.     Wilson  et  al,    (1976,   1977)   and  Bodin  and  Sexton 
(1982)   developed  heuristic  algorithms  for  practical  applications. 
Psaraftis   (1980,   1983a,   1983b,   1983c)    analyzed  and  developed  exact  and 
heuristic  algorithms  for  several  different  versions  of  the  problem. 
Recently,  Jaw  et  al   (1982,   1984)   developed  heuristic  algorithms  for 
multi -vehicle  problems  with  time  ccanstraints. 

The  work  of  Psaraftis   (1983a)   was  an  exact  dynamic  programming 
algorithm  with  forward  recursion,  whose  time  bound  was  0(n  3")   for  a  single 
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vehicle  problem  of  n  customers.     The  objective  of  the  problem  was  to 
minimize  the  time  needed  to  service  all  customers  and  the  algorithm 
identified  infeasible   (with  respect  to  time  constraints)    problem  instances. 

Bodin  and  Sexton   (1982)   formulated  a  mixed-integer  linear 
programming  problem  for  a  one-sided  time  ccaistraint  (desired  delivery  time) 
problem  and     developed  an  algorithm  based  en  Benders'  decomposition  for 
solving   it.     The  objective  was  to  minimize  the  total  "inconvenience" 
customers  may  experience  due  to  excess  ride  time  and  deviation  from  the 
desired  delivery  time.     The  initial  solution  for  the  algorithm  was  obtained 
by  the  "space-time  heuristic",  which  was  a  variant  of  the  "nearest 
neighbor"  heuristic  in  which  the  "measure  of  closeness"  was  represented  by 
a  parameter  called  "space-time  separation".     Later,  Bodin  and  Sexton, 
(1982b)   developed  a  procedure  to  solve  the  multi -vehicle  version  of  the 
problem.     In  this  procedure,   a  "swapper"  algorithm  was  used  to  improve 
vehicle  clusters  and  the  "space-time"  heuristic  was  used  as  a  single 
vehicle  routing  subroutine. 

Jaw  et  al   (1982)   developed  an  algorithm  for  solving  the 
multi -vehicle  dial-a-ride  problem  with  "soft"  tinie-window  constraints.     The 
objective  of  the  problem  was  to  develop  a  set  of  routes  for  a  fleet  of 
vehicles  serving  customers  who  have  to  be  picked  up  from  specified  origins 
and  delivered  to  specified  destinaticxis  so  that  overall  vehicle 
productivity  was  maximized.     The  algorithm  consisted  of  three  successive 
and  distinct  steps:   "grouping",   "clustering",  and  "routing".     Grouping 
divided  customers  into  "time  groups"  on  the  basis  of  their  desired  pickup 
and  delivery  times.     Clustering  separated  customers  of  each  time  group  into 
"clusters"  and  assigns  vehicles  to  serve  each  cluster.     "Itouting"  generated 
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routes  for  each  individual  vehicle  to  serve  every  cluster  in  turn  and  for 
every  time  group. 

In  Jaw  et  al  (1984) ,  the  same  authors  developed  an  "insertion" 
algorithm  for  the  "hard -time -constraint"  version  of  the  problem.  In  this 
version,  the  solution  which  violates  any  of  given  time  constraints  is 
regarded  as  "infeasible".  The  algorithm  sequences  the  customers  in 
ascQiding  order  of  their  earliest  pickup  times.  Then,  customers  are 
assigned  to  different  vehicles  based  on   certain  criteria.  The  current 
requests  are  inserted  into  the  previously  built-up  tour  of  each  vehicle  in 
service.  Amorrj  the  feasible  insertions,  the  one  which  optimizes  the 
objective  value  is  chosen  as  the  best  insert icai.  An  insert icxi  is 
infeasible  if,  as  a  result,  any  service  constraints  are  violated  for  the 
current  request  or  for  any  of  the  customers  cilready  en  board  the  vehicle. 

This  procedure  has  some  potential  for  solving  the  sealift  problem. 
In  fact,  Jeng  (1984)  investigated  the  potential  of  "transferring"  this 
methodology  by  developing  the  framework  for  a  sequential  insertion 
algorithm  for  the  MSC  problem. 

It  is  important  to  point  out  that,  with  the  excepticn  of  the 
dynamic  programming  approach  developed  for  the  single -vehicle  problem  and 
v^ich  is  viable  only  for  very  small  problems,  all  other  dial-a-ride 
algorithms  have  been  heuristic,  especially  the  ones  developed  for  the 
multi -vehicle  problem.  Givai  the  fact  that  the  MSC  problem  is  a 
generalization  of  (and  hence,  more  difficult  than)  the  dial-a-ride  problem, 
it  is  unlikely  that  the  general  version  of  the  MSC  scheduling  problem  can 
be  eventually  solved  efficiently  by  an  exact  (optimization)  approach. 
Moreover,  any  heuristic  (i.e.  approximate)  methodology  that  is  developed 


-37- 


for  this  same  general  versicn  of  the  MSC  scheduling  problem  is  very 
unlikely  to  lend  itself  to  worst -case  or  average-case  analysis.  Such 
analyses  measure  how  good  (in  terms  of  deviation  from  the  theoretical 
optimum)  a  particular  heuristic  algorithm  is  en  a  worst -case  basis  or  on 
the  average  (respectively),  and  can  be  typically  developed  for  simpler, 
more  restrictive  versions  of  a  given  problem.  For  the  MSC  case,  such 
analyses  are  very  interesting  from  a  theoretical  point  of  view,  but  less 
interesting  from  a  practical  point  of  view  because  the  versions  that  are 
amenable  to  such  an  analysis  are  very  restrictive.  In  any  event,  such 
versions  have  been  systematically  analyzed  in  the  Doctoral  dissertation  of 
Kim  (1985)  and  are  briefly  reviewed  in  Chapter  5  of  this  report. 
(2)  The  Bulk  Delivery  Scheduling  Problem 

Another  problem  that  resembles  a  special  case  of  the  MSC  prctolem  is 
one  analyzed  extensively  by  Fisher  et  al  (1982) .  They  considered  the 
problem  of  scheduling  a  fleet  of  vehicles  delivering  a  bulk  product  stored 
at  a  central  depot.  The  objective  of  the  problem  was  to  maximize  the  value 
of  the  product  delivered  to  all  customers,  less  the  fleet  operating  costs 
incurred  in  making  these  deliveries.  They  developed  a  mixed -integer 
programming  formulation  of  the  problem  and  a  solution  algorithm  based  on 
Lagrangian  relaxation  and  a  multiplier  adjustment  method. 

The  algorithm  first  heuristically  generates  a  menu  of  possible 
vehicle  routes  taking  into  account  the  geographical  location  of  customers, 
and  the  amounts  of  demands  and  truckloads.  A  route  is  excluded  if  the 
customers  on  the  route  are  sparead  out  through  a  large  geographical  area  or 
if  the  amount  of  the  product  that  could  be  delivered  to  the  customers  on 
the  route  is  significantly  less  or  significantly  more  than  a  truckload. 
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A  model  is  formulated  to  select  optimally  from  this  mem  of 
possible  routes  a  subset  that  could  actually  be  driven,  specifying  the  time 
each  route  should  start,  the  vehicle  to  be   used,  and  the  amount  to  be 
delivered  to  each  customer  on  the  route.  In  that  case,  the  request  can 
either  be  turned  down  or  another  back-up  vehicle  can  be  added  into  the 
system.  Also,  the  algorithm  has  been  modified  to  accept  vehicle  capacity 
ccBistraints .  Then,  as  a  technique  for  solving  the  problem,  a  Lag rang ian 
relaxation  method  is  used  introducing  a  multiplier  adjustment  method. 

Itie  Lagrangian  relaxation  method  is  an  important  computational 
technique  for  solving  certain  mixed-integer  programming  problems.  The 
rationale  underlying  the  method  is  the  fact  that  many  hard  combinatorial 
problems  can  be  viewed  as  easy  problems  complicated  bay  a  relatively  small 
set  of  side  constraints.  Dualizing  these  side  ccnstraints  (weighing  them 
by  nultipliers  and  placing  them  in  the  objective  function)  produces  a 
Lagrangian  problem  that  is  easy  to  solve  and  whose  optimal  value  is  an 
upper  bound  (for  maximization  problems)  cxi  the  optimal  value  of  the 
original  problem.  Thus,  it  can  be  used  in  place  of  linear  programming 
relaxation  to  provide  bounds  in  a  branch  and  bound  algorithm. 

Recently,  these  same  authors  have  adapted  this  method  to  the 
"peacetime  tanker  scheduling"  problem  of  the  MSC  (Fisher  and  Rosenwein 
1984) .  This  problem  can  be  considered  as  counterpart  of  the  MSC  emergency 
scheduling  problem  in  the  sense  that  the  objective  in  peacetime  operaticxis 
is  similar  to  that  of  a  commercial  shipping  company  (i.e.  minimization  of 
costs)  rather  than  the  timely  delivery  of  the  cargo. 

One  key  corx:eptual  difference  betweai  the  truck  problem  and  the 
tanker  problem  is  the  fact  that  v*iereas  each  truck's  trip  starts  and  ends 
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at  the  same  prescribed  point  (the   depot),  the  endpoints  of  each  of  the 
tankers  in  the  fleet  are  neither  the  same,  nor  necessarily  prescribed  in 
advance.  Tankers  do  not  have  to  return  to  a  central  depot  at  the  end  of 
their  trip.  Indeed,  their  trip  may  ocaisist  of  an  open-ended  sequence  of 
port  visits.  Fisher's  team  handled  this  variation  from  their  original 
model  by  imposing  a  limit  on  the  amount  of  idle  time  each  tanker  could  wait 
at  each  port  and  by  decomposing  the  prc*)lem  and  looking  at  cxie  "time 
horizon"  at  a  time.  For  instance,  they  oould  schedule  ships  within  the 
next  (say)  60  days  (that  is,  ignoring  schedulir^  demands  from  day  61  on) 
with  the  additional  requirement  that  no  ship  should  idle  at  any  port  by 
more  than  (say)  a  week.  Such  a  treatment  served  to  limit  the  number  of 
schedules  generated  by  the  schedule  generator  to  a  manageable  number. 

Fisher's  team  reported  satisfactory  computational  experience  with 
this  procedure  for  a  series  of  test  problems  (Fisher  et  al,  1984).  This 
suggests  that  this  approach  is  certainly  promising  for  the  peacetine  tanker 
scheduling  problem  of  the  MSC.  However,  the  extent  to  which  this 
methodology  can  be  extended  to  solve  the  MSC  operational  problem  is  less 
clear.  The  MSC  operational  problem  involves  in  addition  to  oil  (\^ich  is  a 
bulk  commodity)  general  cargo  as  well,  either  containerized  or  breakbulk. 
This  means  that  a  ship  is  likely  to  carry  a  number  of  different  cargoes  at 
the  same  time.  This  factor  alone  may  make  the  nunfcer  of  schedules  needed 
to  be  generated  by  the  schedule  generator  prohibitively  large.  Moreover, 
it  is  not  clear  how  this  procedure  can  handle  dynamic  updates  of  input 
data.  Thus,  in  additicsi  to  a  significant  amount  of  new  reserch  that  would 
have  to  be  undertaken  to  address  these  and  other  issues,  ws  ccmjecture  that 
this  approach  would  have  to  undergo  a  significant  degree  of  redesign,  most 
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of  it  heuristic,  to  be  tailored  to  the  features  of  the  MSC  operational 
problem. 

2.4     Definition  of  the  Operational  Problem;  Assumpticxis 

As  stated  in  the  project  proposal  (Psaraftis  and  Orlin,  1982),  an 

oversimplified  and  generic  definiticai  of  the  MSC  operaticsial  routing  and 

scheduling  problem  is  the  following: 

Given  a  set  of  available  ships  (located  at  any  given  point  in  time  at 
given  points  somewhere  in  the  ocean)  and  a  set  of  cargoes  (awaiting 
pickup  at  given  ports  of  embarkation  (POE's)  and  requiring  delivery  at 
given  ports  of  debarkation  (POD's)  and  within  specified  time  limits) 
that  is  the  allocation  of  cargoes  to  available  ships  that  "optimizes" 
a  prescribed  delay-related  measure  of  performance? 

After  extensive  discussions  both  within  the  MIT  team  and  with  MSC 

personnel,  the  following  additional  clarifying  assumptions  have  been  made 

regarding  the  definition  of  the  problem  at  hand: 

(1)  The  problem  is  dynamic  in  nature,  that  is,  information  or\  inputs 
such  as  cargoes,  ships,  and  ports  may  (but  does  not  necessarily  have  to) 
become  available  to  the  decision -maker  (the  scheduler)  concurrently  with 
the  decision-making  process.  Previous  information  may  be  updated. 

(2)  The  problem  is  deterministic  in  the  sense  that  no  probabilistic 
information  on  the  input  variables  of  the  problem  is  available.  Issues 
such  as  queueing  and  congestion  at  ports  which  are  inherently  probabilistic 
are  definitely  taken  into  consideration,  but  in  an  ap^oximate,  and 
deterministic  fashion  at  this  stage  of  the  research.  As  will  be  described 
in  Chapter  3  the  queueing  process  is  a  very  important  area  for  further 
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research,  (see  also  Chapter  5) . 

(3)  We  assume  that  all  decisions  ccaicerning  the  node  of  transpDrt  of  a 
particular  cargo  have  been  already  made  at  the  strategic  level.  That  is, 
this  problem  is  not  concerned  with  deciding  en  whether  a  particular  cargo 
should  be  carried  by  the  MSC  or  by  MAC  (the  Military  Airlift  Command). 
Instead,  the  problem  looks  only  at  cargoes  that  have  been  already  assigned 
to  the  MSC  for  transport.  Similarly,  this  problem  is  not  concerned  with 
interactions  between  the  MSC  and  other  Transportation  Operating  Agencies  of 
the  Department  of  Defense,  such  as  MMC  (the  Military  Traffic  Management 
Command),  or  others.  We  assume  that  for  each  cargo,  its  P(3E,  its  POD,  and 
the  time  limits  within  which  its  transport  should  take  place  are  user 
inputs  rather  than  decision  variables.  In  other  words,  deciding  which  is 
the  most  afpropriate  POE  for  a  particular  cargo,  or  determining  when  this 
cargo  is  available  at  its  POE  or  due  at  its  PCO  are  not  part  of  the  problem 
at  hand.  These  important  decision  issues  are  currently  being  investigated 
by  a  Georgia  Tech  project,  sponsored  by  the  Joint  Deployment  Agency   (see 
Jarvis  et  al,  1982) .  These  issues  are  outside  the  scope  of  our  project. 

(4)  We  allow  for  multiple  types  of  ships  and  cargoes  (i.e.  tankers, 
ro/ro  ships,  breakbulk,  etc.),  as  well  as  for  the  splitting  of  a  cargo 
(usually  due  to  size) ,  but  our  methodology  does  not  ccsisider  transfers  of 
cargoes  among  ^ips.  The  implication  of  this  is  that  feeder  operations 
which  would  bring  a  certain  cargo  by  ship  into  a  certain  port,  to  be  picked 
up  subsequently  by  another  ship,  are  not  modeled  by  our  problem.  We  only 
consider  such  cargoes  (if  any)  after  they  have  arrived  (by  whatever  mode) 
at  their  designated  POE's. 

(5)  We  assume  that  each  ship  can  carry  any  number  of  distinct  cargoes 
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(as  long  as  they  are  compatible  and  its  capacity  is  not  exceeded)   and  that 
it  can  make  any  numter  of  stops  on  its  schedule   (to  pick  up  and/or  deliver 
other  cargoes) .     Pickups  and  deliveries  can  be  interspersed  along  the 
route,  and  nultiple  roundtrips  or  triangular  routes  can  be  considered. 

(6)  This  problem  does  not  consider  ship  convoys,  nor  cargo  precedence 
constraints  of  the  form  "this  cargo  should  be  picked  up  before  this  other 
cargo  is  delivered"  or  "cargo  #  37  should  arrive  before  both  cargoes  #  1 
and  #  48  arrive."     Issues  such  as  the  above  might  be  very  important  in 
practice,  but  were  left  for  a  future  phase  of  this  work. 

(7)  Each  cargo  is  assumed  to  have  a  POE,  a  PCD,  an  Earliest  Pickup  Time 
(EPT) ,   an  Earliest  Delivery  Time    (EDT)    and  a  Latest  Delivery  Time    (LDT) . 

Also  the  data  include  the  direct  distance  between  that  cargo's  POE  and  POD, 
its  weight,  volume  and  surface  area.     After  extensive  discussions  with  MSC 
personnel,  we  decided  that  EPT's  and  EOT's  should  be  considered  "hard" 
constraints,  whereas  LDT's  should  be  ccnsidered  "soft".     This  means  that  a 
cargo  cannot  be  picked  up  before  it  becomes  available  at  its  POE   (at  its 
EPT)   and  also  cannot  be  delivered  at  its  POD  before  its  EDT.     This  last 
requirement  was  imposed  because  there  might  be  valid  logistical  reasons  on 
why  a  certain  cargo  cannot  be  delivered  earlier  than  a  prescribed  time 
(lack  of  adequate  support  facilities  etc.).     With  regard  to  a  cargo's  LDT, 
we  decided  that  it  should  be  considered  a  "soft"  constraint   (hence,   is 
amenable  to  violation)   because  we  judged  that  it  would  be  better  to  deliver 
a  cargo  late   (especially  if  it  is  only  a  few  days  late)    than  not  deliver  it 
at  all   (v^iich  could  happen  if  this  constraint  also  were  "hard") .     At  the 
same  time,  and  so  as  to  discourage  late  deliveries,  we  decided  to 
incorporate  a  term  into  our  objective  function  that  penalizes  cargo 
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tardiness  (see  also  Chapter  3) .  Our  model  also  allows  for  the  possibility  of  a 
cargo  not  being  delivered,  in  such  an  event,  that  cargo  would  be  "flagged", 
and  its  due  date  might  subsequently  be  readjusted  after  an  interaction 
between  the  MSC  and  the  authorities  respcxisible  for  issuing  the  cargo 
movement  requirements. 

(8)  The  data  for  each  ship  includes  quantities  such  as  capacity 
(weight/volume/deck  area),  draft,  speed,  cargo  handling  capacity  and 
initial  location.  The  data  for  each  port  includes  the  draft  and  the 
throughput  characteristics  of  its  various  berths  and  terminals. 

(9)  Finally,  we  briefly  discuss  the  objective  function  of  this  problem 
(more  details  will  be  presented  in  Chapter  3) .  From  our  discussion  with 

MSC  personnel  we  concluded  that  there  are  three  primary  events  that  are 
likely  to  create  problems  in  any  given  operational  scheduling  situation, 
and  hence,  should  be  explictly  considered  by  our  approach:   (a)  Late 
delivery  of  cargoes,  (b)  low  ship  utilization  and  (c)  severe  port 
congestion.  The  occurrence  of  any  cne  of  the  above  three  events  is 
considered  an  undesirable  outcome  in  any  operatic»ial  situation,  and 
therefore  should  be  explicitly  penalized.  In  SEACOP,  (a)  and  (b)  have  been 
recognized  to  cause  problems  (Kaskin,  1981) ,  whereas  (c)  has  been 
completely  neglected.  Of  course,  in  reality  (c)  is  ultimately  reflected 
into  (a).  However,  we  thought  important  to  consider  queue ir^  and 
congestion  at  ports  explicitly  rather  than  implicitly  fciecause  of  the 
broader  ramifications  that  this  issue  could  create  in  the  logistics  of  the 
overall  problem.  We  present  the  modeling  of  these  three  criteria  in 
Chapter  3. 
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2.5     Generic  Design  Features  of  an  Operational  Scheduling 

Algorithm  (MIT  Approach) 

Based  on  all  the  previous  ccxisideratiois,  and  after  a  significant 
degree  of  interaction  with  MSC  personnel,  the  MIT  team  came  up  with  a  set 
of  generic  design  features  that  a  computer -assisted  procedure  should 
possess  in  order  to  be  able  to  solve  the  MSC  operational  routing  and 
scheduling  problem.  These  features  are  the  following: 

(1)  It  is  essential  that  such  an  algorithm  be  interactive.  One  should 
always  have  the  "human  in  the  loop"  and  enable  him/her  to  override  the 
computer  at  will.  Various  options  should  be  designed,  ranging  from  a 
completely  "manual"  afproach  where  all  major  allocation  decisicxis  are  made 
by  the  human  operator,  to  more  sophisticated  modes  where  the  computer  deals 
with  more  difficult  problems  (e.g.  routing)  but  still  allows  user 
discretion  for  "key"  decisions,  or  perhaps  even  to  a  fully  automated  mode 
where  the  computer  makes  a  number  of  "default"  assumptions  and  solves  the 
whole  problem  with  no  user  intervention. 

(2)  The  algorithm  should  have  a  "restart"  capability,  that  is,  should 
be  able  to  efficiently  update  schedules  at  any  time  within  the  execution  of 
a  plan,  without  compromising  decisions  already  made.  In  particular,  new 
cargoes  should  be  able  to  be  "inserted"  quickly  into  existing  schedules, 
cargoes  or  ships  that  are  causing  problems  should  be  able  to  be  "deleted", 
etc.  Efficient  list-processing  techniques  (available  at  such  programming 
languages  as  PASCAL  or  PLl)  should  be  implemented  for  fast  database 
manipulations. 

(3)  The  algorithm  should  be  hierarchically  designed,  that  is,  allow  the 
user  to  start  the  dec is ion -making  process  with  "first -cut"  gross 
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feasibility  analyses  (possibly  in  several  levels  of  aggregation)  and  then 
proceed  with  aggregate  scheduling  (that  takes  into  account  only  the  most 
significant  and  best -established  problem  factors,  but  ignores  or  simplifies 
other  factors  that  are  difficult  to  nail  down  -  such  as  queueing  delays) . 
Ultimately,  the  program  would  solve  the  whole  problem  where  all  factors, 
from  the  most  aggregate  to  the  most  detailed,  are  incorporated.  Such  a 
feature  is  considered  important  because  many  significant  insights  may  be 
obtainable  without  having  to  solve  the  v^ole  problem  (e.g.  a  "quick  and 
dirty"  feasibility  analysis  may  establish  that  some  due  dates  are 
infeasible  and  hence  allow  the  user  to  inquire  for  adjustments  before 
further  decisions  are  made) . 

(4)     Finally,  we  consider  it  iinportant  that  this  algorithm  be 
user -friendly.  In  particular,  graphics  aids  are  significant  features  that 
can  enhance  the  efficiency  of  the  man-machine  interaction. 

With  the  above  considerations  in  mind,  let  us  now  reconsider  the 
SAI  methodology  outlined  in  Section  2.2.  It  is  of  course  fair  to  say  that 
the  SAI  algorithm  was  not  designed  for  the  operational  problem  and 
therefore  it  would  be  unreasonable  to  expect  that  approach  to  work  vrell  in 
a  setting  different  from  the  one  it  was  developed  for. 

A  detailed  description  of  the  SAI  methodology  is  beyond  the  scope 
of  this  report.  As  stated  earlier,  SAI  essentially  formulates  the 
deliberate  planning  problem  as  a  "transportatic»i"  problem  whose  objective 
function  incorporates  all  system  costs,  including  those  of  delays,  and 
"solves"  that  problem  by  successive  approximations  in  the  objective 
function.  Those  approximations  are  necessary  since  the  actual  objective 
function  is  (very)  nonlinear  while  the  "transportation"  algorithm 
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can  only  handle  linear  forms.  However,  it  is  unlikely  that  final 
convergence  of  the  assumed  linear  form  to  the  actual  objective  can  be 
always  achieved  or  verified,  due  to  the  intrinsic  nature  of  the  objective 
function. 

The  rest  of  this  section  discusses  whether  the  SAI  algorithm  (a) 
currently  has  the  features  outlined  earlier  and  (b)  if  not,  what  changes 
would  be  necessary  to  incorporate  such  features: 

(1)  Interactive  feature:  SAI  either  does  not  have  it,  or  has  it  in  a 
very  crude  form.  We  expect  that  making  the  ajxroach  interactive  would  not 
be  difficult  conceptually,  in  principle,  but  that  it  would  involve  a 
substantial  amount  of  new  software  development. 

(2)  Restart  capability;  SAI  does  not  have  this  capability  currently. 
Introducing  the  feature  could  be  done  to  some  extent,  although  it  would 
involve  some  thinking  as  to  how  to  make  the  algorithm  "remember"  previous 
assignments.  More  difficulty  is  expected  whenever  one  or  a  few  cargoes 
need  to  be  "inserted"  into  existing  schedules  (actually,  the  SAI  FORTRAN 
algorithm  may  be  quite  cumbersome  in  doing  this) .  In  all  cases, 
substantial  new  software  development  would  be  necessary. 

(3)  Hierarchical  design:  SAI  has  that  feature,  but  only  to  a  certain 
extent.  For  instance,  its  first  iteration  is  in  itself  a  gross  flexibility 
analysis.  However,  SAI  falls  short  of  incorporating  some  very  important 
features  into  the  problem.  The  most  important  of  those  is  queue ing  at 
ports.  It  is  not  clear  to  us  whether  SAI  can  be  modified  so  that  queueing 
is  explicitly  taken  into  account. 

(4)  User-friendly/graphics  feature:  SAI  does  not  have  the  feature,  but 
it  would  be  relatively  straightforward  to  impiement  it. 
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It  is  clear  from  the  above  assessment  that  it  would  be  rather 
difficult  to  modify  the  SAI  algorithm  to  functicai  in  an  operational 
setting.  Similar  conclusions  can  be  reached  regarding  the  other 
methodologies  described  in  Section  2.4.  of  this  chapter.  Givai  that  the 
prospects  of  an  exact  solution  method  are  remote,  the  MIT  team  developed  a 
heuristic  procedure  which  is,  by  design,  specifically  tailored  to  the 
nature  of  this  problem.  This  procedure  is  described  in  the  following 
chapter . 
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CHAPTER  3 
THE  MQE^SS  ALGCRITHM 

3.1  Introduction 

MCRSS  is  an  acronym  for  MIT  Ocean  Routing  and  Scheduling  System.  It 
consists  of  four  subsystems,  READIN,  DISPLAY,  SEEDS,  and  SCHEDULE. 

The  first  subsystem,  READIN,  creates  and  initializes  all  data 
structures  and  reads  in  all  data.  The  second,  DISPLAY,  is  a  menu-driven, 
data  management  subsystem  v\^ich  oiables  and  aihances  the  interactive  nature 
of  MQESS.  The  third  subsystem,  SEEDS,  initializes  the  scheduling  process 
by  assigning  a  maximum  of  one  cargo  to  each  ship.  The  fourth  subsystem, 
SCHEDULE,  is  the  main  functional  part  of  MORSS.  Its  purpose  is  to  form  a 
schedule  for  each  ship,  based  on  the  given  cargo  movement  requirements. 
The  flow  logic  for  these  subsystems  is  given  in  Figure  3.1.  Details  en  the 
data  structure  design  are  given  in  Appendix  A  of  this  report.  Details  on 
the  organization  of  the  routines  as  well  as  flowcharts  are  givai  in 
Appendices  B  and  C. 

In  the  rest  of  this  chapter  we  concentrate  en  the  approach  we  have 
used  the  routines  associated  with  SGHEEXJLE.  We  discuss  the  assumptions, 
problems,  movitations  and  rationale  which  led  us  to  structure  these 
routines  as  we  have. 

3.2  The  Scheduling  Subsystem 

This  section  contains  a  detailed  descripticHi  and  explanation  of  the 
scheduling  subsystem  SCHEDULE.  SCHEDULE  operates  after  seed  assignments 
have  he&n  made  -  (more  on  this  in  Section  3.5) .  Its  function  is  to  assign 
cargoes  to  ships  so  as  to  maximize  the  net  overall  utility  of  all 
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assignments.  It  does  this  by  follcwing  the  sequence  of  steps  outlined 
below  (details  follow) : 

Step  0;  Initialize  "master  list"  of  unassigned  cargoes. 
Set  up  overall  horizon  (0,T) (T:user  inpjt) 

Select  length  of  Individual  time  horizons  L  (user  input :0<_Lf^T) 
Select  fraction  a  (user  inpat:  0£a<^l) 
Set  k=l,  t^=o. 
Step  1;  Set  up  next  time  horizon  (t.  ,t|^+L) 

Form  list  of  cargoes  eligible  for  assignment  (all  cargoes 
in  "master  list"  whose  EPT's  are  between  t,  and  t.+L)  • 
Step  2;  Calculate  assignment  utilities  for  all  eligible 

cargo/ship  pairs  (see  section  3.2). 
Step  3;  Form  and  optimize  a  transportation  network  using  assignment 

utilities  as  arc  costs.  Resulting  assignment  forms  the  "tentative 
assignment"  for  time  horizon  (t.  ,  t, +L) . 
Step  4:  Return  (a)  all  unassigned  cargoes  by  Step  3,  (b)  all  tentatively 
assigned  cargoes  whose  EPT's  are  between  t,+aL  and  t.+L,  and  (c) 
all  tentatively  assigned  cargoes  v^ich  interact  unfavorably  with 
other  assigned  cargoes,  into  "master  list"  of  unassigned  cargoes. 
Make  all  other  cargo/ship  assignments  in  (t  ,t. +aL)  "permanent" 
and  remove  correspondirq  cargoes  from  "master  list"  of  unassigned 
cargoes.  Remove  any  "infeasible  cargoes"  (see  Secticai  3.5)  from 
"master  list"  of  unassigned  cargoes. 
Step  5;   "Roll"  time  horizon:  Set  t,  ,  =  Lowest  EPT  of  all  cargoes  in 

"master  list"  of  unassigned  cargoes.  Set  ]<?=k+l  and  go  to  Step  1. 
MORSS  is  based  on  a  "rolling  horizon"  scheme  (see  Figure  3.2).  The 
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ROT.T.TNG  HORIZON 


Figiire  3 . 2 
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rolling  horizon  is  a  decomposition  of  the  problem  by  time.  The  overall 
scheduling  horizon  T  (which  can  be  of  the  order  of  180  days  for  long-range 
problems)  is  subdivided  into  time  horizons  of  shorter  duration  L  (say,  of 
the  order  of  two  weeks).  Within  these  shorter  time  horizons,  assignments 
are  made  first  on  a  tentative  basis,  and  only  cargoes  within  the  "front 
end"  of  L  are  considered  for  permanent  assignment.  Parameter  a  specifies 
what  fraction  of  L  cargo  assignments  may  be  considered  to  become  permanent. 
Thus,  if  Ii=2  weeks  and  a=0.5,  MORSS  will  "look"  at  two  weeks  of  cargo  data 
at  a  time,  and  at  each  iteration  will  assign  only  cne  week  of  cargoes. 

There  are  several  positive  features  in  this  "rolling  horizon" 
approach  :  First,  we  piace  a  lesser  emphasis  en  the  less  reliable  future 
information  on  cargo  movements.  This  advantage  is  of  particular  importance 
in  emergency  situations  where  movement  information  more  than  several  weeks 
in  advance  may  be  subject  to  a  number  of  alterations.  Our  approach  focuses 
each  iteration  en  near -term  events  but  also  has  a  look -ahead  capability  so 
that  future  scheduled  events  are  taken  into  account.  In  addition,  the 
initial  ship  positions  are  modeled  explicitly  within  our  framework.  For 
these  reasons,  we  believe  that  a  time-decomposition  approach  is 
appropriate. 

A  crucial  aspect  of  our  approach  is  that  the  future  is  taken  into 
account  through  information  contained  in  adjacent  time  intervals.  In 
particular,  most  ship  voyages  are  scheduled  over  two  consecutive  intervals. 
The  rolling  horizon  concept  enables  this  connection  of  successive  time 
intervals  by  examining  o/er lapping  time  horizons.  Thus,  t^^-,  will  be 
typically  smaller  than  tj^  +L  (see  Figure  3.2)  (an  exception  would  occur  if 
there  are  no  cargoes  having  EPT's  between  t.^,  and  t,^+L) . 


-53- 


In  Step  0  (initialization),  and  since  the  overall  problem  is 
dynamic  in  nature,  the  value  of  the  time  horizon  length  T  may  not 
necessarily  be  known  to  the  scheduler  in  advance.  In  this  case,  T  is  set 
at  some  arbitrarily  large  value. 

We  now  describe  our  modeling  of  the  of  utilities  for  each  eligible 
cargo/ship  pair. 
3.3  Assignment  Utilities 

Within  each  time  frame,  MORSS  makes  assignments  of  cargoes  to  ships 
while  taking  into  account  assignments  made  in  previous  periods.  At  the  k 
iteration,  MCRSS  has  already  assigned  cargoes  leaving  prior  to  t  .  In 

K 

addition,  some  previously  assigned  cargoes  may  have  pickup  and/or  delivery 
times  scheduled  after  tj^.  Because  any  subsequent  assignment  could  cause 
changes  in  the  anticipated  delivery  times  of  previously  assigned  cargoes, 
the  utility  of  a  proposed  assignment  takes  into  account  both  the  projected 
delivery  time  of  the  assigned  cargo  and  its  effect  en  the  delivery  times  of 
previously  scheduled  cargoes. 

In  addition,  we  will  not  assign  too  many  ships  to  cargoes  in  the 
k   scheduling  horizon  so  as  to  be  able  to  satisfy  requirements  for  pickups 
in  the  subsequent  two  time  horizons.  In  addition  we  model  the  delays 
caused  by  queueing  at  ports.   (Our  current  model  of  queueing  delays  is  a 
simple  nonlinear  estimate.  We  expect  to  refine  our  model  in  the  future.) 

These  considerations  lead  us  to  ccxiclude  that  the  utility,  or  value 
of  a  proposed  new  cargo/ship  assignment  must  depend  on  the  following 
factors: 

(1)  the  assignment's  effect  on  the  delivery  time  of  the  cargo  to  be 
considered  for  assignment; 
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(2)  the  assignment's  effect  oi  the  delivery  time  of  previously 
assigned  cargoes; 

and 

(3)  the  assignment's  effect  en  the  system's  ability  to  handle  future 
cargo  movement  requirements: 

(a)  use  of  ship  resources  over  the  aitire  scheduling  horizon; 

(b)  use  of  port  resources  over  the  entire  scheduling  horizoi. 

We  now  discuss  each  of  these  factors  in  detail: 

3.3.1  Delivery  Time  Utility  (For  a  Proposed  Assignment) 

In  calculating  this  utility,  and  as  we  already  mentioned  in  Chapter  2, 
we  consider  both  the  Earliest  Pickup  Time,  (EPT) ,  and  the  Earliest  Delivery 
Time  (EDT) ,  to  be  "hard"  constraints,  that  is,  these  constraints  cannot  be 
violated.  We  point  out,  however,  that  MDRSS  could  be  easily  modified  to 
handle  "soft"  EPT's  and/or  EDT's.  This  modification  could  be  incorporated 
via  changes  to  the  method  of  calculating  utilities,  and  would  also  increase 
the  number  of  feasible  schedules. 

Although  the  EDT  and  EPI  constraints  are  hard,  we  treat  the  latest 
delivery  (LDT)  LDT  requirements  as  soft.  To  illustrate  why,  ws  consider 
a   specified  cargo  movement  requirement  such  that  a  combination  of  EPT, 
EDT,  and  LDT  times  is  demonstrably  infeasible.  Specifically,  in 
MSC-suppLied  data  (see  also  Chapter  4)  we  have  found  a  number  of  deiranstrably 
infeasible  cargo  movements  arising  from  the  following  situaticHis:   (1)  the 
fastest  ship  of  a  given  type  is  too  slow  to  transport  a  cargo  within  the 
specified  EPT-LDT  interval;   (2)  only  one  ship  can  be  available  (at  a 
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specific  time)  to  satisfy  as  many  as  (say)  three  cargo  movement 
requirements:  It  may  pick  up  and  deliver  any  two  of  the  three  cargoes 
within  their  specified  EPT-LDT  intervals,  but  for  a  variety  of  reasons  it 
may  not  be  able  to  do  so  for  all  three;  (3)  cargo  movement  requirements 
greatly  exceed  total  available  fleet  capacity;  and  finally  (4)   port 
throughput  limitations  cause  queuing  delays  at  PCJE's  and  PCO's.  In 
addition,  other  factors  such  as  ship-port  restricticxis,  delays  and 
medium-term  saturation  of  shipping  resources  lead  to  LOT  infeasibility  for 
sets  of  cargoes.  For  these  reasons  we  assume  that  the  LOT  constraints  are 
"soft",  that  is,  may  be  violated  if  necessary.  We  can  then  incorporate 
penalties  for  LDT  violations  into  our  objection  function. 

Given  that  latest  delivery  times  are  negotiable,  we  ask  the  question: 
How  does  the  "value"  (or  "goodness")  of  a  delivered  cargo  change  as  a 
function  of  delivery  time?  After  extensive  discussions  with  MSC  personnel, 
we  decided  to  answer  this  question  as  follcws:  First  of  all,  each  cargo  c  has 
a  maximum  possibile  utility,  say  u(c).  If  the  cargo  is  delivered  early  or 
on  time  (that  is,  if  it  arrives  betwesi  its  EOT  and  its  LOT)  its 
corresponding  value  is  the  maximum  u(c).  If  it  is  only  a  few  days  late 
(say  1  or  2  days  after  its  LOT)  we  assume  its  value  is  lower  than  u(c),but 
very  close  to  maximum.  If  it  is  more  than  a  few  days  late  we  assume  its 

value  decreases  rapidly  with  delivery  time  delay  until  it  reaches  a  minimum 
value,  at  some  time  LOT  +  t^,  ^q   assume  that  delivery  beycxid  LOT  +  t^  does 
not  substantially  change  the  value  of  the  delivered  cargo,  with  that  value 
remaining  at  its  minimum.  Parameter  t.  is  user -input  for  each  cargo,  and 
is  cargo-dependent.  We  have  set  t.  =  14  days  for  the  initial  calibration 
of  MORSS.  By  this  assumption,  a  cargo  delivered  2  weeks  after  its  UJT   is 
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worth  about  the  same  as  if  it  were  delivered  4  weeks  after  its  UDT. 

There  are  several  pDssible  functional  forms  for  the  delivery  time 
utility  of  a  cargo,  all  of  which  fit  the  above  assumptions  well.   We  have 
chosen  a  bell-shaped  function  because  it  is  smooth  and  continuous  and  also 
matches  our  intuition  better.  It  is  also  flexible  due  to  four  free 
parameters.  A  mathematical  formulation  for  a  bell-shaped  function  follows. 


Let 

U  =    Delivery  time  utility 

V  .  =    Minimum  utility  (for  very  late  cargo) 

^max  "    Maximum  utility  (for  on  time  cargo) 

t  Tardiness  of  cargo  (Arrival  time  -  LDT  if  >0,  zero  otherwise 

t»  =    Time  for  which  U  =  V„.  +  0.1(V^^^-V„.  ) 
0  c    mm       max  min' 

b  =    ^k)nnegative  exponent 

Then 

U      =    V  .  +  (V    -  V  .  )e~^^^'^^0^  I-.   nx 

c  min   ^  max    min'^  (i.i) 


The  four  parameters  V  .       v       ,   t^  and  b  are  user -inputs,   and,   in 
general,  cargo -de  pendent   (particularly  V  .     and  V„^^) . 

Graphs  of  U    for  several  values  of  b     are  shown  in  Figure  3.3.     Note 
that  the  case  b  =  2  corresponds  to  a  shape  similar  to  the  curve  for  the 
Gaussian  Probability  Density  Function. 
3.3.2     A  Proposed  Assignment's  Effect  en  Previously  Assigned  Cargoes 

In  our  analysis  of  the  effect  of  a  proposed  assignment  en  other 
previously  assigned  cargoes,  we  assume  that,  given  a  cargo's  delivery  time, 
that     cargo's  utility  is  independent  of  the  delivery  time  of  any  other 
cargo.     Specifically,  for  each  cargo  j,  we  assume  that  V^^^^^^,  V^^^^j^,   tg  and 
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b  are  particular  to  cargo  j ;  that  is,  they  are  independent  of  the  delivery 
times  of  all  other  cargoes. 

This  assumption  is  reasonable  given  we  have  assumed  no  precedence 
constraints  en  the  deliveries  of  cargoes  (see  Qiapter  2) .  In  the  real 
world,  exceptions  to  this  rule  may  occur.  For  instance,  delivering  a 
particular  cargo  en  time  might  be  worthless  (or  evai  might  be  undesirable) 
if  some  other  cargo  has  not  been  previously  delivered.  If  such  ocaistraints 
do  exist,  MORSS  handles  them  by  user  interventicxi  and  not  internally. 

Because  of  the  independence  assumption,  the  marginal  effect  of  a 
proposed  cargo/ship  assignment  on  the  delivery  time  utilities  of  other 
cargoes  would  be  equal  to  the  change  in  total  delivery  time  utility  of  all 
previously  assigned  but  yet  undelivered  cargoes  (scheduled  to  be  delivered 
by  the  ship  in  question  only,)  that  occurs  because  of  the  addition  to  the 
proposed  new  cargo  en  that  ship.  In  other  words,  the  effect  of  a  proposed 
assignment  en  a  set  of  known  assignments  is  the  difference  in  the  total 
delivery  time  utilities,  with  and  without  the  proposed  assignment.  More 
rigorously,  let 

AU     =  effect  of  a  proposed  assignment  on  the  utility  of 
cargoes  l,...,n  (already  assigned  to  same  ship) 

U.    =  utility  of  cargo  j  in  original  schedule  (without 
n&ri   assignment) 

Ul     =  utility  of  cargo  j  in  schedule  vi^ich  includes  pickup 
and  delivery  of  proposed  assignment. 


Then 


n 
AU  =  Z   (u!  -  U.)  (3.2) 

j=l   ^     3 
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3.3.3  A  Proposed  Assignment's  Effect  en  the  System's  Ship  Resources 

The  primary  motivation  for  this  utility  component  is  that  ship 
resources  are  limited.  There  are  a  limited  number  of  ships.  Because  of 
this  limitation  we  wish  ships  to  sail  as  fully  loaded  as  possible.  Thus 
ship  utilization  is  important  in  assessing  the  goodness  of  a  potential 
assignment. 

It  is  rarely  possible,  however,  to  achieve  100%  utilization  on  any 
leg  of  a  ship's  journey.  Indeed,  many  ships  often  return  (to  pick  up 
additional  cargo)  on  ballast,  which  significantly  decreases  the  average 
utilization.  In  addition,  a  high  utilization  may  be  impossible  for  a  given 
problem.  This  might  be  because  of  the  EPT/EDTAJ3T  structure  of  the 
problem.  For  instance,  in  MSC-suppLied  data  ve  have  seen  that  the 
assignment  of  a  cargo  to  a  ship  severely  limits  that  ship's  ability  to  pick 
up  and  deliver  other  cargoes  en  time. 

Looking  at  the  use  of  ship  resources  in  another  way,  and  comparing 
two  potential  cargo  assignments  for  a  ship,  (everything  else  being  equal) , 
we  will  tend  to  prefer  the  one  which  gives  the  ship  the  most  flexibility 
(in  terms  of  available  slack  in  that  ship's  schedule)  in  carrying 
additional  cargoes.  Thus,  "schedule  flexibility"  is  also  important  in 
assessing  the  goodness  of  a  potential  assignment. 

The  value  of  "ship  utilization"  and  of  "schedule  flexibility"  are 
related  in  the  following  way:  In  terms  of  ship  resources,  the  optimal 
ccndition  is  for  the  ship  to  be  full.  In  this  case  schedule  flexibility  is 
unimportant  since  the  ship  can  pick  up  no  additional  cargoes.   (We  assume 
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most  tripG  are  from  an  area  of  POE's  to  an  area  of  POD's  with  no  -  or  few  - 
pod's  in  between).  Here  ws  have  maximum  utilization  of  shipping  resources. 
The  worst  situation  is  for  a  ship  to  be  empty  (or  nearly  so) ,  and,  to  have 
no  schedule  flexibility.  Here  the  ship  is  essentially  worthless,  since  it 
is  both  almost  empty  and  has  little  flexibility  in  its  schedule  to  pick  up 
new  cargo.  This  is  the  case  where  the  ship  is  deadheading  and  en  a  tight 
schedule.  Here  we  have  zero  use  (i.e.  waste)  of  shifping  resources. 
Intermediate  between  these  extremes  is  the  situation  where  the  ship  is 
empty  and  has  maximum  schedule  flexibility.  This  is  the  case  where  the 
ship  has  no  future  deliveries  scheduled  yet.  Here  no  shipping  resources 
are  being  used  -  the  ship  is  empty  -  yet  shipping  resources  are  available 
because  of  the  schedule  flexibility.  In  this  case  we  give  a  low,  but 
intermediate  value  for  utilization  of  ship  resources,  or  ship  utility. 
These  combinations  are  summarized  in  Table  3.1. 


Ship  Condition 

Full 
Full 

Enpty 
Rnpty 


Schedule  Flexibility 

High 
Low 
High 
Low 


Ship  Utility 

Maximum 
Maximum 
Low 
Minimum 


Table  3.1 


For  intermediate  values  of  ship  utilization  and  of  schedule 
flexibility,  ship  utility  is  an  increasing  function  of  each  component. 

There  are  several  functional  forms  which  fit  the  above 
characterization  of  ship  utility.  Again  we  chose  a  bell-shaped  model  for 
MORSS  for  two  reasons.   (1)  It  more  closely  reflects  our  belief  that 
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utility  should  change  more  rapidly  at  the  intermediate  ranges  of  the 
compcnents  than  near  the  extreme  values,  and  (2)  its  specific  form  is 
flexible  due  to  five  free  parameters. 

A  mathematical  formulation  for  such  a  bell -shaped  function  follows: 
Let 

Ug    =  Ship  utility  at  a  stop. 
V    =  Maximum  value  of  ship  utility 
R    =  Residual  capacity  of  ship  after  the  stop 
C    =   hip  capacity 
F    =  Schedule  flexibility  (slack  in  schedule  averaged 

over -all  future  stops) 
L     =  Scheduling  horizon  length 
c,d    =  Non-negative  user  inputs 

f     =  User- input  0  <  f  <  1 


Then 

s    s 

A  graph  of  this  two-dimensional  surface  appears  in  Figure  3.4. 

Note  that  the  value  of  this  utility  is  different  at  each  stop  en  a 
ship's  schedule.  For  any  given  stop,  its  value  depends  on  the  fractional 
ship  utilization  ijnmediately  after  the  stop  (i.e.  between  the  stop  and  the 
following  stop) ,  and  on  schedule  flexibility  averaged  over  all  future 
stops.  As  a  result,  the  value  of  ship  utility  for  a  proposed  assignment 
must  be  a  combination  of  ship  utility  at  the  pickup  and  at  the  delivery. 
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Ship  loaded  to 
capacity 


F/L 


enpty  ship 


Figure  3.4 
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We  have  chosen  to  ac3d  these  two  utilities  directly,  so  that 

Ug  =  Ug(  pickup)  +  Ug  (delivery)  (3.4) 

where  U  =  total  ship  utility  for  an  assignment. 

Our  motivation  for  this  choice  is  that  is  canputationally  simple  and 
achieves  our  desired  objective  of  oicouraging  assignments  vAiich  utilize 
fewer  ship  resources. 
3.3.4  A  Proposed  Assignment's  Effect  on  the  System's  Port  Resources 

The  motivation  of  this  utility  component  is  that  port  throughput 
capacity  is  limited,  and  queueing  can  cause  oiormous  delays  and  waste  over 
the  long  run,  because  of  idle  ships.  Because  of  this  limitation  ve   wish  to 
discourage  additional  ships  from  stopping  at  ports  when  they  are  near  or 
over  throughput  capacity.  In  this  case  we  wish  to  encourage  a  ship  which 
has  already  been  assigned  to  a  pDrt  for  another  task,  to  handle  the  pickup 
or  delivery  of  other  cargoes  in  that  port  within  the  same  time  frame.  Our 
method  is  the  following.  We  divide  the  overall  scheduling  horizon  into  a 
series  of  "congestion  periods"  of  length  p.   (We  chose  p=3  for  the  initial 
calibration  runs) .  We  then  keep  track  of  the  number  of  stops  at  each  port 
for  each  of  the  congestion  periods. 

The  congestion  level  for  a  period  is  defined  as  the  ratio  of  the 
number  of  scheduled  stops  in  the  period  divided  hy  the  total  throughput 
capacity,  measured  in  number  of  ships,  of  the  period.  Since  these 
congestion  levels  depend  en  the  number  of  stops  scheduled  so  far,  and  these 
numbers  change  with  each  new  set  of  assignments,  MCRSS  updates  them  at  each 
iteration. 
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Port  congestion  and  the  value  of  port  utility  for  a  proposed  cargo 
novement  (pickup  or  delivery)  are  related  as  follows.  The  optimal 
condition  is  whai  no  additional  stop  is  required  to  fulfill  the  movement.  A 
ship  already  assigned  bo  the  port  can  do  the  job.  Here  no  additicaial  port 
resources  are  used,  so   the  value  of  port  utility  is  maximum.  If,  however, 
an  additional  ship  oitry  into  the  port  is  required  to  fulfill  the  task, 
then  the  situation  is  more  complex  and  will  in  all  cases,  exhibit  a  lowsr 
utility.  At  higher  levels  of  port  congestion,  available  port  resources  are 
scarcer,  so  their  value  is  higher.  Similarly,  at  lower  levels  of 
congestion,  port  resources  are  abundant,  hence  cheaper  to  use. 
Consequently  port  utility  is  a  decreasing  function  of  congestion. 

There  are  several  functional  forms  which  fit  this  description  of 
port  utility.  As  before,  the  bell-shaped  curve  is  more  attractive  because 
it  is  smooth  and  is  flexible  because  of  four  free  parameters.  A  sample 
grafh  is  shown  in  Figure  3.5. 

A  mathematical  formulation  for  the  bell -shaped  curve  is  given 
below,  for  the  value  of  port  utility  at  a  stop. 


U 
ps 


W  If  no  additional  stop  is  required 
P 

-2(iTiN/P)  If  an  additional  stop  is  required. 
P^  (3. 5  J 


where 

U   =  Port  utility  for  the  stop 

W    =  Maximum  value  of  port  utility  if  no  additional  stop  is  required 

Vjj   =  Maximum  value  of  port  utility  if  additional  stop  required 

N    =  Number  of  stops  in  port  during  congestion  period  in  question 
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P    =  Throughput  capacity  of  port,  per  congestion  period 
m,l  =  Nonnegative  oonstants. 

Since  this  utility  is  different  for  each  stop  en  a  ship's  schedule, 
the  total  value  of  port  utility  for  a  proposed  assignment  must  be  a 
combination  of  the  port  utilities  at  the  pickup  and  at  the  delivery.  We 
have  chosen  to  add  these  two  utilities  directly  so  that 

Up=  Upg  (pickup)  +  Upg  (delivery).  (3.6) 

where  U  =  total  port  utility  for  the  assignment. 

Our  motivation  for  this  approach  is  that  it  achieves  our  primary 
objective:  encouraging  assignments  \n^ich  utilize  fewer  port  resources, 
v^ile  being  computationally  simple.  This  functional  form  is  but  a  first 
approximation  of  the  queueing  process  at  a  port,  a  process  which  in  itself 
merits  further  investigation  (see  also  Chapter  5). 
3.3.5  Total  Assignment  Utility 

Our  previous  discussion  has  shown  that  the  utility  of  a  proposed 
assignment  depends  on  four  factors: 

(1)  its  own  delivery  time 

(2)  its  effect  on  other  cargoes'  delivery  time, 

(3)  its  use  of  system  ship  resources,  and 

(4)  its  use  of  (system)  port  resources. 

For  this  initial  phase  of  the  project,  we  have  expressed  the  total 
assignment  utility  as  a  weighted  sum  of  four  utility  components. 
Mathematically, 

U^.  =  U  +  AUp,  +  U  +  U^  (3.7) 

t     C       D      S      p 

where 
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U^   =      Total  utility  of  an  assignment 

U    =      Delivery  time  utility  for  the  assignment 

A  Up    =      Effect  of  the  assignment  another  cargoes  U  's 

U    =      Ship  utility  for  the  assignment 
s 

U    =      Port  utility  for  the  assignment. 

Note  that  the  weighting  factors  for  the  component  utilities  are 
implicit  in  their  calculaticns,  because  of  the  terms  V  .   v   ,  U  ,  W_, 
and  U   A  major  part  of  the  (initial)  calibraticn  of  the  model  will  be 
determining  af^opriate  relative  values  for  these  weighting  factors. 

We  now  turn  to  the  question  of  hew  SCHEDULE  determines  the 
assignment  utility  for  a  given  ship-cargo  pair.  SCHEDULE  does  this  in 
several  steps.  First,  an  incompatibility  may  exist  if  the  ship  type  and 
cargo  types  do  not  match  or  if  the  port  facilities  at  POE  or  POD  cannot 
handle  the  ship  because  of  draft,  beam,  heavy  lift,  etc.  constraints.  In 
this  case  the  assignment  utility  is  given  a  large  negative  value.  Then 
SCHEDULE  examines  a  set  of  possible  ways  to  insert  the  cargo's  pickup  and 
delivery  into  the  ship's  existing  schedule.  For  each  of  these  insertion 
possibilities,  SCHEDULE  computes  a  utility  value.  If  every  insertion 
possiblity  yields  a  net  decrease  in  overall  delivery  time  utility,  i.e  if 
U  +  AO^  <0  for  all  insertion  possibilites,  then  the  assignment  utility 
is  given  a  negative  value.  Otherwise  from  those  insertion  possibilities 
which  realize  a  net  increase  in  overall  delivery  time,  SCHEDULE  chooses  the 
one  with  the  maximum  overall  utility.  The  utility  of  the  assignment  is 
then  set  equal  to  the  utility  of  this  insertion  possibility. 
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3.4  Solving  t±ie  Assignment  Problan 

As  we  have  noted  previously,  the  main  source  of  c»mpLexity  in  the 
Sealift  problem  is  common  to  a  broad  class  of  scheduling  problems.  The 
extreme  complexity  of  the  problem  stems  from  the  non-linear  interact icns 
between  utilities  of  different  ship/cargo  assignments.  The  utility  of  any 
cargo-ship  assignment  is  directly  dependent  upon  the  assignment  of  other 
cargoes  to  that  ship.  It  is  also  indirectly  dependent  on  queueing  at 
ports -of -call,  caused  by  cargo  assignments  bo  other  ships.  As  previously 
discussed,  our  approach  is  to  decompose  this  problem  by  time  into  smaller 
problems,  one  per  scheduling  horizon.  This  decomposition  reduces  the 
compilexity  of  the  problem  by  several  orders  of  magnitude,  but  does  not 
bypass  it  entirely.  The  remaining  complexity  may  be  addressed  by  the 
question  :  On  v^iat  basis  do  we  simultaneously  assign  cargoes  to  ships  when 
the  assignment  utilities'  strongly  depend  on  how  ships  schedules  are 
modified  by  the  assignments  themselves?  There  are  several  possibilities. 

One  approach  is  to  simultaneously  assign  all  cargoes  within  the 
scheduling  horizon,  using  utilities  calculated  from  previous  schedules. 
This  has  the  advantage  of  simplicity  and  speed,  but  it  ignores  cargo 
interactions.  We  have  thus  rejected  this  approach. 

A  second  af^oach  is  to  assign  cargoes  one  at  a  time,  starting  with 
the  one  with  the  highest  assignment  utility,  or  the  one  with  the  earliest 
EIPT,  and  then  recomputing  utilities  of  all  other  eligible  cargoes  based  on 
that  assignment.  This  approach  has  the  advantage  of  taking  into  account  bad 
interactions  in  a  myopic  way.  It  fails  to  capture  the  favorable 
interactions  between  compatible  sets  of  cargoes.  It  is  also 
computationally  slow.  A  modification  of  the  second  approach  is  to  assign 
one  cargo  per  ship  and  then  recompute  utilities  at  each  iteration.  This 
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forces  shipe  to  have  the  same  number  of  cargoes,  and  fails  to  capture 
favorable  interactions. 

A  third  approach  is  to  eiumerate  all  possibilities.  This  method  is 
computationally  too  expensive.  There  are  of  course  many  other 
modifications  and  types  of  approaches.  From  the  three  described  above,  we 
may,  however,  deduce  principles  frcm  vrfiich  to  select  an  appropriate 
heuristic.  We  wish  at  the  same  time  and  with  a  reasonable  computational 
effort,  to:   (1)  capture  as  many  favorable  interactions  as  possible,  and 
(2)  eliminate  bad  interactions  between  assignments. 

It  should  be  clear  that  we  are  in  a  tradeoff  situaticxi  with  respect 
to  these  goals.  We  have  therefore  chosen  a  heuristic  solution  methodology 
which  is  a  compromise  between  achieving  the  two  goals.  The  heuristic 
allows  multiple  simultaneous  assignments  for  each  ship,  via  an  optimally 
solved  transportation  problem.  It  assigns  cargoes  within  each  scheduling 
horizon,  rejecting  assignments  which  have  strong  negative  interactions. 
Thus  the  algorithm  maintains  the  computational  speed  of  simultaneous 
assignments  and  the  "goodness"  of  a  solution  which  takes  interactions  into 
account.  The  rest  of  this  section  contains  a  detailed  description  of  the 
heuristic  (additional  details  en  its  computer  implementaticfi  are  in 
Ap^ndix  B) . 

Once  assignment  utilities  are  calculated  for  all  eligible 
ship/cargo  pairs,  they  are  used  to  create  a  transportation  network,  (see 
Figure  3.6).  The  network  is  bipartite.  Ships  are  sources,  and  eligible 
cargoes  are  sinks.  To  speed  up  the  algorithm  and  to  avoid  excessive 
ncxi-linear  interactions  ships  are  given  a  user-input  integral  supply  of  S 
(we  chose  S=4  for  the  initial  calibration  runs) .  S  is  the  maximum  number 
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of  simultaneous  cargo  assignments  each  ship  may  receive  at  any  individual 
iteration  (scheduling  horizcn) .  Cargoes  are  given  a  demand  of  1  to  reflect 
the  fact  that  it  must  be  assigned  to  a  ship.  In  the  network  all  compatible 
ship-cargo  pairs  are  connected  by  directed  arcs  (from  ships  to  cargoes) 
whose  costs  are  the  negatives  of  the  corresponding  assignment  utilities. 
In  addition,  for  bookkeeping  pjr poses  we  create  a  dummy  ship  and  a  dummy 
cargo. 

The  dummy  ship  has  arcs  to  all  real  cargoes,  each  with  "high"  cost. 
It  is  givQi  an  infinite  supply,  so  it  may  take  as  many  cargoes  as 
necessary.  Its  function  is  to  take  any  cargoes  which  are  not  assigned  to 
other  ships  for  any  reascai  (incompatibility,  limited  shipping  resources, 
etc) .  The  dummy  cargo  serves  the  following  internal  bookkeeping  function: 
It  balances  demand  in  the  case  where  there  is  more  ship  supply  than 
cargoes.  To  accomplish  this,  it  has  one  arc  from  each  real  ship,  each  with 
a  "high"  cost.  When  the  network  is  complete  it  is  sent  to  subroutine 
FLOSUB.  This  routine  finds  an  optimal  solution  to  the  transportation 
problem.  It  maximizes  the  net  overall  utility  of  assignments  in  the 
scheduling  horizon,  while  assigning  each  cargo  (dummy  and  real)  to  one  ship 
(dummy  or  real) .  The  routine  FLOSUB  uses  an  especially  fast  method  written 
by  Orlin  (1983a,  1983b) .  The  mechanics  are  described  in  more  detail  in 
Appendix  B.  The  routine  outputs  a  list  of  tentative  feasible  ship-cargo 
assignments.  How  these  are  dealt  with  is  described  belcw. 
3.5  Permanent  Assignments 

At  each  iteration  MORSS  divides  the  tentative  assignments  in  the 
interval  (t,  ,  t.  +  L)  returned  by  FLOSUB  into  three  categories:  (1)  new 
assignments  v*iich  are  unique  to  a  ship;  (2)  new  assignments  which  are  not 
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unique  to  a  ship  (that  is,  there  is  more  than  one  tentative  assignment  to 
the  ship);  and  (3)  assignments  to  the  dummy  ship.  These  are  treated  as 
follows. 

Assignments  which  are  unique  to  a  ship  are  made  permanent.  There 
are  no  non-linear  interactions  with  other  cargoes  assigned  to  the  ship. 

Assignments  v*iich  are  not  unique  to  a  ship  are  further  divided  by 
ship.  On  each  ship,  the  tentative  assignment  with  the  earliest  EPT  is  made 
permanent.  The  remaining  tenative  assignments  en  the  ship  are  looked  at  in 
order  of  increasing  EIPT.  One  by  one  their  assignment  utility  is 
recalculated  based  on  the  ship  schedule  updated  by  newly  made  permanent 
assignments.  If  the  net  decrease  in  utility  is  less  than  a  user -input 
critical  value  (percentage  and/or  absolute  measure  of  change)  the 
assignment  is  made  permanent.  If  the  decrease  in  utility  is  more  than  the 
critical  value,  then  the  cargo  is  returned  to  the  pool  of  unassigned 
cargoes . 

Assignments  to  the  dummy  ship  are  also  returned  to  the  pool  of 
unassigned  cargoes.  Assignments  v*iose  EPT  falls  in  the  interval  (t,  +  aL, 
t|^  +  L)  are  not  assigned  permanently.  Their  function,  as  discussed 
previously,  is  to  link  successive  scheduling  horizons.  They  are  all 
returned  to  the  list  of  unassigned  cargoes. 

When  a  permanent  assignment  is  made,  it  may  happen  that  the  cargo 
is  too  large  for  available  ship  capacity.  In  this  case  the  cargo  is  split. 
As  much  as  possible  goes  on  the  ship,  and  the  remaining  amount  is  returned 
to  the  pool  of  unassigned  cargoes  for  the  next  iteratioi. 

In  order  to  prevent  endless  cycling  caused  by  an  infeasible  cargo, 
we  limit  the  number  of  times  a  cargo  may  be  returned  to  the  pool  of 
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unassigned  cargoes.  Once  it  has  exceeded  that  number  {vie   chose  4, 
initially) ,  it  is  added  to  the  list  of  infeasible  cargo  movement 
requirements.  It  is  therefore  possible  that  MORSS  will  leave  some  cargoes 
unassigned.  This  is  sometimes  the  most  desirable  outcome.  Numerous 
examples  of  infeasibilities  exist  in  the  MSC  -  supplied  database,  as 
already  discussed  in  section  3.3.1.  However,  WJBSS   leaves  cargoes 
unassigned  only  when  the  available  alternatives  have  greater  utility. 
Since  utility  decreases  with  delivery  time,  unassigned  cargoes  are 
possible. 
3.6  Seed  Assignments 

Another  concept  central  to  MORSS  is  the  concept  of  "seed" 
assignments.  This  is  a  one-to-one  assignment  of  some  cargoes  (seed 
cargoes)  to  some  ships  early  en  in  the  scheduling  process  so  that  a  good 
starting  solution  is  obtained.  Such  a  solution  serves  as  a  "skeleton"  for 
the  final  schedule,  which  gradually  evolves  from  the  seed  schedule  as 
subsequent  assignments  are  made  at  future  iteraticxis.  As  in  other 
assignments,  seed  selection  is  performed  by  solving  an  assignment  problem 
whose  objective  function  is  the  maximization  of  the  total  "utility"  of  the 
assignment.  For  each  eligible  seed  cargo/ship  pair,  we  again  compute  the 
"utility"  of  the  corresponding  pair.  The  main  differences  between  seed 

assignments  and  subsequent  assignments  are  (a)  seed  assignments  are  made  on 
a  cxie-to-one  basis  whereas  in  subsequent  assignments  more  than  one  cargo 
can  be  simultaneously  assigned  to  a  ship,  and  (b)  subsequent  assignments 
take  into  account  assignments  already  made  at  prior  iterations  while  this 
is  not  applicable  in  seed  assignments. 

At  the  present  stage  of  our  research,  seed  assignments  are  selected 
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by  the  MOFBS  user   in  an  interactive  fashion.     We  anticipate  developing  a 
utility-based  assignment  approach,   as  discussed  above,   in  the  next  phase  of 
our  research. 
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CHAPTER  4 
CCMPUmTIC»IAL  EXPERIENCE 
4.1     IntrcxJuction 

In  this  chapter  we  describe  our  computational  experience  with  the 
MORSS  algorithm  as  it  relates  to  data  supplied  to  us  by  the  MSC.  We  should 
menticxi  at  the  outset  that  the  data  we  have  used  so  far  have  been 
"sanitized"  by  the  MSC  so  as  to  avoid  the  disclosure  of  sensitive 
information.  Such  a  "sanitization"  process  has  been  necessary  given  the 
unclassified  nature  of  the  MIT  project  (or,  of  any  MIT  research  project  for 
that  matter).  This  chapter  begins  with  a  brief  description  of  the  MSC 
database  (Section  4.2)  and  proceeds  with  a  presentation  of  gross 
feasibility  analyses  that  have  been  made  with  respect  to  the  data  (Section 
4.3).  Section  4.4  outlines  our  initial  experience  with  the  MORSS 
algorithm,  performed  on  a  small  subset  of  the  MSC  database,  including  an 
interpretation  of  the  results. 
4.1    The  MSC  Database 

The  MSC  database  includes  information  on  505  cargoes,  232  ships  and 
26  ports. 

Each  of  the  cargoes  is  either  a  single  item  or  a  collection  of 
items  that  have  a  distinct  POE  and  a  distinct  POD.  In  addition,  each  cargo 
has  a  preferred  ship  type,  an  EPT,  an  EDT  and  an  LOT.  Also  known  is  that 
cargo's  Short  Tcxis  (STONS) ,  its  Measurement  Tcxis  (^f^ONS)  and  its  Deck  Area 
(SQFT) .  The  505  cargoes  are  classified  into  8  categories,  according  to 
preferred  ship  type:  These  are  breakbulk  (193  cargoes) ,  seatrain  (13 
cargoes) ,  RD/RO  (151  cargoes) ,  self-sustaining  container  (54  cargoes) , 
tanker  (45  cargoes),  and  barge  carrier  (25  cargoes),  while  4  cargoes  are  of 
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an  unspecified  ship  preference. 

Ships  are  classified  into  3  fleet  types  and  6  ship  types:  Ttie 
fleet  type  codes  are  MSC -controlled  (38  ships) ,  Ready  Reserve  (38  ships) 
and  Sealift  Readiness  Program  (156  ships) .  The  ship  type  codes  are 
breakbulk  (100  ships),  seatrain  (5  ships),  RD/RO  (5  ships),  self-sustaining 
container  (9  ships),  tanker  (25  ships)  and  barge  carrier  (18  ships). 
Information  on  ships  includes  capacity  (weight/volume/deck  area),  draft, 
speed,  cargo  loading  and  unloading  rates,  as  well  as  initial  location. 

Finally,  the  26  ports  of  the  MSC  database  are  classified  as 
follows:  12  are  POE's,  5  are  POD's,  and  the  remaining  9  are  both  PQE's  and 
pod's.  All  ports  of  the  database  are  located  in  the  United  States,  the 
Panama  Canal  Zone  and  the  Pacific.  Information  en  ports  includes  the 
throughput  characteristics  of  their  various  berths  and  terminals.  All 
inter -port  distances  are  also  known. 

Various  statistics  of  the  MSC  database  (such  as  range  of  cargo 
sizes,  general  cargo  movement  patterns,  etc) ,  have  been  reported  in  Chapter 
5  of  Jeng  (1984) .  Here  we  focus  on  analyses  that  can  be  quickly  performed 
to  ascertain  the  gross  feasibility  ofa  particular  problem  instance.  The 
following  section  provides  the  rationale  that  has  been  used  oi  that  score. 
4.3     Gross  Feasibility  Analysis 

Given  a  particular  "problem  instance"  (that  is,  a  set  of  prescribed 
inputs  for  the  MSC  operaticffial  problem) ,  we  have  assumed  that  the  scheduler 
would  like  to  know  early  on  in  the  decision-making  process  to  what  extent 
this  particular  instance  is  feasible.  That  is,  the  scheduler  would  like  to 
obtain  a  preliminary  idea  regarding  whether  available  resources  are  enough 
to  satisfy  the  prescribed  cargo  movement  requirements.  If  the  of^site 
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turns  out  to  be  the  case,  it  would  make  little  sense  to  proceed  with  a 
detailed  scheduling  run,  because  most  cargoes  would  be  delivered  late. 
Instead,  it  would  then  make  sense  to  relay  infeasibility  information 
immediately  to   the  chain  of  command  "upstream",  so  that  either  the  cargo 
movement  requirements  are  modified,  or  additional  resources  aire  made 
available,  or  some  other  measure  is  taken  to  alleviate  this  problem.  Thus, 
the  NOT  team  considered  important  that  a  set  of  simple  feasibility  tests  be 
developed,  so  that  a  "quick-and-dirty"  picture  of  the  feasibility  (or  lack 
thereof)  of  a  particular  instance  is  established. 

Gross  feasibility  analysis  can  be  performed  at  various  levels  of 
detail.  At  the  simplest  level,  one  can  check  whether  the  prescribed  cargo 
delivery  time  requirements  alone  are  reasonable  or  unreasonable  by 
performing  a  screening  test  that  will  be  described  below.  Such  a  test  is 
always  an  optimistic  estimator  of  feasibility,  in  the  sense  that  any 
problem  instance  identified  by  the  test  as  "bad"  is  always  infeasible, 
whereas  an  instance  not  identified  as  "bad"  is  not  necessarily  feasible. 
Such  an  instance  (that  is,  one  that  has  "passed"  this  first  feasibility 
screening  test)  can  be  further  tested  for  feasibility  by  more  sophisticated 
tests  (see  later  description),  and,  ultimately,  be  fed  as  input  to  MORSS 
for  detailed  scheduling.  Of  course,  if  a  problem  instance  fails  to  pass 
this  first  screening  test,  it  is  "rejected"  and  sent  back  to  the  chain  of 
command  upstream  for  further  acticHi. 

As  said  before,  the  simplest  screening  test  that  can  be  performed 
concerns  cargo  information  only.  For  a  particular  cargo,  define  SLACK (V)  = 
(LDT-EPT)  -  (Direct  transit  time  between  that  cargo's  FOE  and  POD  if  ship 
speed  is  V  knots) .  This  represents  the  maximum  time  slack  between  that 
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cargo's  actual  delivery  time  and  its  LDT,  under  the  optimistic  assumption 
that  the  cargo  leaves  its  POE  immediately  at  its  EPT  and  travels  directly 
to  its  POD. 

Define  also  for  that  cargo  SSPEED  as  the  ratio  of  its  PCE/POD 
distance  divided  by  (LDT  -  EDT)  and  expressed  in  knots.  This 
optimistically  represents  the  minimum  ship  speed  required  if  the  cargo 
leaves  its  POE  promptly,  is  delivered  to  its  POD  at  its  LDT,  and  travels 
directly. 

Figure  4.1  is  a  histogram  of  SLACK (15)  for  all  193  cargoes 
belonging  to  the  breakbulk  category  (that  is  the  largest  cargo  class  in  the 
MSC  database  by  number) .  Since  many  of  those  cargoes  have  negative 
SLACK (V),  ana  since  this  statistic  is  only  an  optimistic  representation  of 
the  actual  slack  time,  the  histogram  shows  that  delivering  all  of  these 
cargoes  on  time  is  virtually  impossible,  irrespective  of  both  actual  ship 
resources  and  scheduling  strategy. 

A  similar  conclusioi  can  be  drawn  for  Figure  4.2,  which  is  a 
histogram  of  SSPEED  for  the  same  cargo  sample.  Given  it  is  rather  unlikely 
to  have  breakbulk  ships  with  speeds  of  more  than  25  knots  immediately 
available,  we  can  conclude  that  meeting  cargo  deadlines  for  this  problem 
instance  is  virtually  impossible,  whatever  ships  are  available  and  whatever 
algorithm  is  used  for  the  scheduling. 

Similar  observations  were  made  in  the  MSC  database  on  virtually  all 
other  cargo/ship  categories.  Put  in  another  way,  the  MIT  team  discovered 
that  the  MSC-supplied  database  suffered  from  a  widespread  degree  of  gross 
infeasibility,  at  least  as  far  as  the  possibility  of  meeting  cargo  due 
dates  was  concerned.  From  our  discussions  with  MSC  personnel,  we 
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understood  that  the  infeasibility  of  the  database  could  be  attributed  in 
part  to  the  "sanitization"  process  that  was  used  to  convert  the  database 
from  classified  to  unclassified.  Other  factors  might  be  valid  as  well, 
such  as  the  facts  that  in  practice  a  cargo's  EPT  and  LOT  are  sometimes  (if 
not  always)  determined  by  two  different  (and  sometimes  unrelated)  decision 
processes.  As  a  result,  a  cargo's  LOT  usually  reflects  neither  that 
cargo's  availability  at  its  POE,  nor  its  POE/POD  distance  (In  fact,  in  the 
MSC  database  we  even  found  that  in  some  cases  a  cargo  had  an  LOT  which  was 
earlier  than  its  EPT  -  a  clearly  absurd  requirement) . 

As  a  result  of  the  above,  the  MIT  team  decided  to  use  only  smaller, 
more  manageable,  and  closer -to -feasible  parts  of  the  MSC  database  to  test 
the  MORSS  algorithm.  This  made  sense  since  we  did  not  want  to  begin  the 
testing  of  MDRSS  with  huge,  grossly  infeasible  amounts  of  data.  In  the 
meanwhile,  another  database  was  prepared  by  the  MSC  and  sent  to  MIT  for 
further  testing.  This  new  database  arrived  at  MIT  rather  late  for 
inclusion  in  this  report  (August,  1985) .  This  new  database  would  be  used 
in  conjunction  with  further  calibration  and  testing  of  M3RSS  (see  also 
Chapter  5). 

Before  we  describe  our  limited  computational  experience  with  MORSS, 
we  corclude  this  section  by  outlining  a  second-level,  more  sophisticated 
gross  feasibility  test.  Such  a  test  could  be  used  for  data  that  have 
passed  the  first  test  outlined  earlier. 

By  contrast  to  the  previous  test  which  oompietely  ignores  ship 
resource  information,  that  is,  is  based  only  en  an  evaluation  of  "demand" 
(cargo-related/requirements,  this  seccxid-level  test  takes  also  into  account 
the  "supply"  side  of  the  problem,  that  is,  the  ability  of  available  ships 
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txD  meet  that  demand. 

The  second-level  test  formulates  the  feasibility  problem  as  a 
"transportation"  problem.  It  sets  up  a  bipartite  network  very  similar  to 
the  one  described  in  Chapter  3,  with  supply  node  i  (i=l,...,m)  representing 
ship  i,  and  demand  node  j(j=l,...,n)  representing  cargo  j.  Let  a.  be  the 
capacity  of  ship  i,  w.  be  the  size  of  cargo  j  and  c- ■  be  the  tardiness  of 
delivering  cargo  j  by  ship  i,  assuming  a  direct  and  ijnmediate  service  by 
ship  i  from  the  POE  to  the  PCD  of  cargo  j.  We  then  define  as  x.  .  the  capacity 
of  ship  i  allocated  to  cargo  j  and  solve  the  following  transportation 
problem: 


m   n 

minimize 

Z    Z 
i=l  j-1 

C.  .X.  . 

13  13 

s.t. 

n 

Z  X.  . 

3=1  '' 

m 

<  a. 

—  1 

(i  =  1. . .  ,m) 

Z  X.  . 
i=l  ^^ 

=  w. 
3 

(j  =  l,..,n) 

"ij 

>  0 

It  is  clear 

that  the 

optimal 

value  of  this  problem  is  a  lower  bound 

en  the  actual  total  weighted  tardiness  (ton-days  late)  that  would  incur 
under  any  actual  allocation  of  available  ships  to  cargoes.  Such  a  test  is 
actually  identical  to  the  first  iteration  of  SAI's  transportation  algorithm 
(SAI,  1982).  Again,  as  in  the  previous  case,  this  test  is  optimistic  in 
the  sense  that  it  always  identifies  a  "bad"  instance  but  may  not 
necessarily  correctly  proclaim  one  as  "good".  The  latter,  in  a  sense,  can 
only  be  assessed  after  detailed  scheduling  has  been  attempted. 

Given  the  above  consideraticns  regarding  the  "reasonableness"  of 
the  MSC-suppO-ied  database,  the  scope  of  any  test  runs  of  MORSS  with  that 
database  became  immediately  limited.  Nevertheless,  in  spite  of  the 
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infeasibilities  of  the  database,  we  began  testing  the  algorithm  with 
subsets  of  the  data.  This  is  described  in  the  following  section. 
4.4    M3RSS  Test  Runs 

We  chose  a  subset  of  the  MSC  database  for  the  initial  runs  of  MORSS 
with  certain  goals  in  mind.  For  ease  of  analysis  ws  wanted  ships  and 
cargoes  to  be  of  compatible  types.  We  desired  the  problem  size  to  be  at 
once  small  enough  to  easily  manage  and  comprehend,  and  large  enough  to 
ccxitain  the  complexities  of  the  MSC  operaticaial  problem.  Finally,  we 
wanted  a  nontrivial  problem,  one  which  reflected  to  some  extent  the 
infeasibility  of  some  of  the  time  windows  in  the  MSC  database.  In  short, 
we  sought  for  a  representative  database  for  the  initial  runs. 

To  meet  these  goals,  we  selected  a  set  of  twenty  breakbulk  cargoes. 
The  lot's  of  these  cargoes  ranged  from  day  8  to  day  42.  Their  size  ranged 
from  10  measurement  tons  to  264,414  measurement  tons.  The  POE's  included 
four  Atlantic-side  ports  from  New  York  to  Galveston,  three  Pacific-Side 
ports  from  Los  Angeles  to  Seattle,  and  four  Pacific  Ocean  island  locations. 
The  pod's  included  the  Phili pines,  Malaysia  and  Eastern  Australia.  We  took 
relevant  information  for  each  of  these  ports  (e.g.  depth,  width,  interport 
distances)  from  the  MSC  database. 

In  analyzirq  the  cargo  data,  we  found  that  the  roundtrip  time  of  a 
ship  was  long  in  comparison  to  the  range  of  the  cargo  LOT's.  This 
precluded  the  possibility  of  multiple  trips  by  the  same  ship.  We  therefore 
modified  the  EPT,  EOT,  LOT  times  to  cover  a  98-day  span.  This  change 
allowed  a  relatively  small  number  of  ships  to  meet  most  of  the  prescribed 
cargo  movement  requirements,  while  completing  as  many  as  four  (4) 
roundtrips  in  the  Pacific  theatre,  and  two  (2)  roundtrips  from  East  Coast 
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PCE's.  Cargo  characteristics  are  listed  in  Table  4.1. 

We  diose  a  fleet  of  seven  (7)  ships  for  the  initial  runs.  Their 
speed  ranged  from  432  to  552  nautical  miles  per  day.  Their  capacity  ranged 
from  3,800  to  19,125  measurement  tons,  and  from  6,000  to  7,500  square  feet 
of  deck  space.  For  each  ship,  vge  took  availability  times  at  each  port  from 
the  MSC-pcovided  database,  as  well  as  other  relevant  ship  characteristics, 
e.g.  draft,  beam,  boom  capacity,  etc. 

Our  objective  in  the  initial  computaticnal  study  was  twofold. 
First,  we  wanted  to  verify  that  MORSS  was  operating  correctly  and  in  a 
manner  consistent  with  its  design.   Secondly,  we  desired  to  begin  the 
gross-scale  calibration  of  the  model,  that  is,  empirically  testing  the 
effect  of  seed  assignments,  cargo  size  and  time  window  arrangement  en  the 
quality  of  the  overall  solution  (see  also  Chapter  5) .  Our  procedure  was 
also  two-fold.  First,  we  tested  MQF?SS  on  increasingly  larger  problems 
until  we  were  satisfied  that  the  model  was  debugged.  Thai  we  began  the 
gross-calibration  study,  which  we  now  discuss. 

The  initial  runs  confirmed  our  intuition  that  seed  assignments 
greatly  influence  the  quality  of  the  final  schedule.  Our  strategy  was  to 
try  a  variety  of  seed  assignments  in  order  to  gain  a  measure  of  the 
quantitative  effects  of  this  key  factor.  These  assignments  were  made 
randomly  at  first,  then  varied  to  test  various  hypotheses  about  what 
constitutes  "good"  seed  assignments.  In  particular,  we  attempted  to 
improve  the  quality  of  the  solution  (e.g.  decrease  the  number  of 
undelivered  cargoes)  by  modifying  the  assignment  of  seeds  from  one  run  to 
the  next. 

The  complete  man-machine  session  for  the  first  run  (Data  Set  A)  is 
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Cargc 

# 

) 

POE 

POD 

KP'l' 

EDT 

LOT 

A 

Quantity 
B 

(tons) 
C 

1 

Los  Angeles 

Philippines 

5 

14 

20 

10680 

- 

- 

2 

S.  Japan 

Malaysia 

5 

20 

27 

14830 

- 

4830 

3 

Norfolk 

Philippines 

11 

10 

30 

4150 

- 

14150 

4 

Galveston 

Philippines 

12 

14 

35 

690 

6900 

- 

5 

New  York 

Malaysia 

18 

28 

40 

10 

1000 

- 

6 

Charleston 

Malaysia 

25 

25 

47 

30 

3000 

- 

7 

Norfolk 

Philippines 

25 

5 

53 

195200 

9520 

- 

8 

Charleston 

Malaysia 

31 

10 

57 

264140 

26414 

12641 

9 

Norfolk 

Philippines 

34 

19 

60 

29030 

- 

12903 

10 

Hawaii 

Philippines 

35 

9 

65 

7430 

- 

- 

11 

San  FranciFm 

Philippines 

45 

13 

69 

190 

1900 

- 

12 

Wake 

Philippines 

45 

45 

73 

1950 

- 

- 

13 

Norfolk 

Philippines 

50 

26 

78 

30 

3000 

- 

14 

Charleston 

Malaysia 

55 

30 

80 

16480 

6480 

- 

15 

Okinawa 

Malaysia 

55 

4 

84 

24650 

2465 

- 

16 

Okinawa 

Malaysia 

57 

6 

87 

51880 

5188 

- 

17 

Okinawa 

Malaysia 

60 

2 

90 

4120 

- 

- 

18 

Japan 

Malaysia 

65 

6 

92 

1910 

- 

- 

19  - 

S.  Japan 

Philippines 

65 

11 

94 

150 

1500 

- 

20 

New  York 

Australia 

70 

33 

98 

17550 

7550 

_ 

Table  4.1:  Cargo  Data  Set  (A,  B,  C  are  variants) 
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displayed  in  Table  4.2.  These  results  show  the  effect  of  a  gross 
infeasibility  in  the  problem  structure.  Two  cargoes  (#7  and  #8)  are  very 
large:  Together  they  require  25  trips  by  the  largest  ship.  The  next 
largest  three  cargoes  require  6  roundtrips.  By  contrast,  the  smallest  five 
cargoes  fill  3.0%  of  the  smallest  ship.  This  large  disparity  between  ship 
size  and  cargo  movement  requirements  allows  only  11%  of  the  total  cargo 
weight  to  be  delivered  on  time,  while  35%  of  the  total  number  of  cargoes 
arrive  on  time.  Because  of  this  gross  infeasibility,  ws  modified  the 
measurement  tons  of  twelve  of  the  cargoes  to  even  out  the  spread.  The 
revised  numbers  (Data  Set  B)   appear  in  Table  1,  column  B.  For  this  data 
set  only  two  cargoes  require  multiple  shipx-trips.  Surnmary  statistics  from 
runs  2,3,  and  4  appear  in  Tables  4.3,  4.4  and  4.5  respectively  (the 
complete  man-machine  sessions  are  omitted  due  to  space  limitations) . 
These  runs  use  seven  ships  and  several  seed  assignment  configurations. 
Some  infeasibility  remains  since  less  than  50%  of  the  tons  are  delivered  on 
time,  arri  at  most  60%  of  the  cargoes  arrive  en  time.  We  decided  to  further 
modify  the  cargo  sizes  to  make  the  problem  more  feasible,  but  first  we 
tried  to  improve  the  ship  utilization,  which  is  less  than  7%  for  these 
runs.   (Note  that  in  measuring  ship  utilization  we  also  count  ballast  legs, 
in  which  utilization  is  zero.  This  means  that  if  a  schedule  includes 
ballast  legs  and  multiple  rountrips,  ship  utilization  should  not  be 
expected  to  be  high  -  see  also  discussion  at  the  end  of  this  section) . 
To  this  end   we  made  three  runs  (summary  statistics  in  tables  4.6,  4.7  and 
4.8)  with  5  ships  in  various  seed  configurations.  As  anticipated,  ship 
utilization  rose,  to  an  average  of  10.6%.  The  percentage  of  tons  delivered 
on  time  dropped  by  nearly  half,  and  the  number  of  cargoes  delivered  on  time 
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R;  T-0.01/0.01  14:03:35 
SCHED 

EXECUTION  BEGINS. . . 
8  SUPERCOMPLEXES 

DONE  READING  IN  COMPLEX  AND  PORT  DATA 

READ  IN    20  CARGO  RECORDS 
-,  READ  IN     7  SHIP  RECORDS 

ENTER  OUTPUT  STREAM  RATING,  SCALE    0  TO   10 
1 

OUTPUT  SET  AT      1 

••*   SEEDS   •»* 
INPUT  SHIP  AND  CARGO  NO. 

1  1 

INPUT  SHIP  AND  CARGO  NO. 

2  2 

INPUT  SHIP  AND  CARGO  NO. 

3  3 

INPUT  SHIP  AND  CARGO  NO. 

4  4 

INPUT  SHIP  AND  CARGO  NO. 

5  5 

INPUT  SHIP  AND  CARGO  NO. 

6  6 

INPUT  SHIP  AND  CARGO  NO. 

7  7 

INPUT  SHIP  AND  CARGO  NO. 
0 

INPUT  WIDTH  .LIMIT 
99  20 


SCHEDULE  FOR  SHIP  NO     1: 

TYPE   MTON   SOFT  SPEED 

1  14125   6000  432 

DATE  CMP  NAME  P_D  OUANT   RMRTN  SLK  CRG  EPT  EOT  LOT   MTON  TYPE 

14    9  L.A.   P  10680    3445    O    1   5   14   20   10680     1 

29   21  PHIL   0  10680   14125    O    1   5   14   20   10680     1 

54    5  CHAR   P  14125        0    O    8  31   10   57  264140     1 

82   22  MALA   D  14125   14125    0    8  31   10   57  264140     1 


*********••***•< 


.».•«.»»»»•*•**•»••••••»*•»*•*••*••••••••••*• 


SCHEDULE  FOR  SHIP  NO.    2: 
TYPE   MTON   SOFT   SPEED 
1  14467   6000     444 

DATE  CMP  NAME  P  D   OUANT   RMRTN  SLK  CRG  EPT  EOT  LOT   MTON  TYPE 


32 

14 

SOAP 

P 

14467 

0 

0 

2 

5 

20 

27 

14830     1 

38 

22 

MALA 

0 

14467 

14467 

0 

2 

5 

20 

27 

14830     1 

65 

14 

SJAP 

P 

1910 

12557 

21 

18 

65 

6 

92 

1910     1 

71 

22 

MALA 

D 

1910 

14467 

0 

18 

65 

6 

92 

1910     1 

88 

1  1 

SEAT 

P 

150 

14317 

0 

19 

65 

1  1 

94 

150     1 

Table  4.2(a):  7  Ships,  Original  Data  Set  (A) 
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101   21  PHIL 


150   14467 


19  65   11   94 


150 


>**»***< 


»•**♦•♦♦••< 


••*•*•♦*•*••« 


SCHEDULE  FOR  SHIP  NO.    3: 

TYPE   MTON   SOFT  SPEED 

1  14467   6000  444 

DATE  CMP  NAME  P  D  OUANT   RMRTN  SLK  CRG  EPT  EOT  LDT   MTON  TYPE 


11 

4 

NORF 

P 

4  150 

10317 

1 

3 

1  1 

10 

30 

4  150     1 

36 

21 

PHIL 

D 

4  150 

14467 

0 

3 

1  1 

10 

30 

4  150     1 

45 

13 

WAKE 

P 

1950 

12517 

3 

12 

45 

45 

73 

1950     1 

51 

21 

PHIL 

D 

1950 

14467 

0 

12 

45 

45 

73 

1950     1 

76 

5 

CHAR 

P 

14437 

30 

0 

14 

55 

30 

80 

16480     1 

77 

4 

NORF 

P 

30 

O 

O 

13 

50 

26 

78 

30     1 

102 

21 

PHIL 

D 

30 

30 

0 

13 

50 

26 

78 

30     1 

105 

22 

MALA 

D 

14437 

14467 

0 

14 

55 

30 

80 

16480     1 

k************************************!) 


•*♦♦*♦•***♦*****♦♦•♦♦*•* 


SCHEDULE  FOR  SHIP  NO.    4: 

TYPE   MTON   SOFT  SPEED 

1  14467   6000  444 

DATE  CMP  NAME  P  D  OUANT   RMRTN  SLK  CRG  EPT  EDT  LDT   MTON  TYPE 


14 

8 

GALV 

P 

690 

13777 

0 

4 

12 

14 

35 

690     1 

39 

21 

PHIL 

D 

690 

14467 

0 

4 

12 

14 

35 

690     1 

53 

10 

S.F. 

P 

190 

14277 

0 

1  1 

45 

13 

69 

190     1 

58 

18 

HAWA 

P 

7430 

6847 

0 

10 

35 

9 

65 

7430     1 

69 

21 

PHIL 

D 

7430 

14277 

0 

10 

35 

9 

65 

7430     1 

69 

21 

PHIL 

D 

190 

14467 

0 

1  1 

45 

13 

69 

190     1 

95 

2 

N.  Y. 

P 

14467 

0 

0 

20 

70 

33 

98 

17550     1 

117 

24 

AUST 

D 

14467 

14467 

0 

20 

70 

33 

98 

17550     1 

♦♦•♦*••♦*••*•*• ♦.* ♦♦♦****••***♦♦♦♦♦***♦**••«•**»♦**♦*♦*•♦♦•**** 

SCHEDULE  FOR  SHIP  NO.    5: 
TYPE   MTON   SOFT   SPEED 
1  13800   6000     432 

DATE  CMP  NAME  P  D   OUANT   RMRTN  SLK  CRG  EPT  EDT  LDT   MTON  TYPE 


25 

4 

NORF 

P 

13790 

10 

1 

7 

25 

5 

53 

195200     1 

26 

2 

N.  Y. 

P 

10 

0 

0 

5 

18 

28 

40 

10     1 

52 

21 

PHIL 

D 

13790 

13790 

0 

7 

25 

5 

53 

195200     1 

55 

22 

MALA 

D 

10 

13800 

0 

5 

18 

28 

40 

10     1 

60 

17 

OK  IN 

P 

13800 

0 

0 

15 

55 

4 

84 

24650     1 

65 

22 

MALA 

D 

13800 

13800 

0 

15 

55 

4 

84 

24650     1 

93 

2 

N.  Y. 

P 

3083 

10717 

0 

20 

70 

33 

98 

17550     1 

115 

24 

AUST 

D 

3083 

13800 

0 

20 

70 

33 

98 

17550     1 

**«***«*********«*****4*»******»*4i***************  +  *****  +  *«**** 


SCHEDULE  FOR  SHIP  NO.    6: 
TYPE   MTON   SOFT   SPEED 
1  19125   7500     552 


Table  4.2  (b) 
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DATE 

CMP 

NAME 

P  0 

QUANT 

RMRTN 

SLK 

CRG 

EPT 

EOT 

LOT 

MTON  TYPE 

25 

5 

CHAR 

P 

30 

19095 

1  1 

6 

25 

25 

47 

30     1 

47 

22 

MALA 

D 

30 

19125 

0 

6 

25 

25 

47 

30     1 

57 

17 

OK  IN 

P 

4155 

14970 

6 

16 

57 

6 

87 

51880     1 

55 

17 

OK  IN 

P 

10850 

4120 

2 

15 

55 

4 

84 

24650     1 

60 

17 

OK  IN 

P 

4  120 

0 

9 

17 

60 

2 

90 

4  120     1 

64 

22 

MALA 

D 

4155 

4155 

0 

16 

57 

6 

87 

51880     1 

68 

17 

OK  IN 

P 

4  155 

0 

0 

16 

57 

6 

87 

51880     1 

72 

22 

MALA 

D 

10850 

10850 

0 

15 

55 

4 

84 

24650     1 

76 

17 

OK  IN 

P 

10850 

0 

0 

16 

57 

6 

87 

51880     1 

80 

22 

MALA 

D 

4  120 

4  120 

0 

17 

60 

2 

90 

4  120     1 

84 

17 

OK  IN 

P 

4  120 

0 

0 

16 

57 

6 

87 

51880     1 

88 

22 

MALA 

0 

4155 

4155 

0 

16 

57 

6 

87 

51880     1 

88 

22 

MALA 

D 

10850 

15005 

0 

16 

57 

6 

87 

51880     1 

88 

22 

MALA 

D 

4  120 

19125 

0 

16 

57 

6 

87 

5  1880     1 

**********4 


>*«********«•«*****••*»*•*•***«*••**•*•****«****«** 


SCHEDULE  FOR  SHIP  NO. 
TYPE   MTON   SOFT   SPEED 
1  19125   7500     552 


DATE  CMP  NAME  P_D  QUANT 

25    4  NORF   P  19125 

45   21  PHIL   D  19125 

65    5  CHAR   P  2043 

87   22  MALA   D  2043 


RMRTN  SLK  CRG  EPT  EDT  LDT   MTON  TYPE 

Oil    7  25    5   53  195200  1 

19125    0    7  25    5   53  195200  1 

17082    0   14  55   30   80   16480  1 

19125    0   14  55   30   80   16480  1 


'******«•! 


'***««***«•*••**«*****•* 


UNSCHEDULED  CARGOES: 

CRG   POE   NAME   POD   NAME   EPT   EDT   LDT   MTON   TYPE 


2 

14 

SJAP 

22 

MALA 

5 

20 

27  14830       1 

7 

4 

NORF 

21 

PHIL 

25 

5 

53195200       1 

8 

5 

CHAR 

22 

MALA 

31 

10 

57264140       1 

9 

4 

NORF 

21 

PHIL 

34 

19 

60  29030       1 

6 

17 

OKIN 

22 

MALA 

57 

6 

87  51880       1 

***•**•*•••*••*••*••»***••****•*«*****•« «*«I 


•**•»••***»•»**•**••**»*»*< 


>***«*•****•**«*•*** 


SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  =  8.80 

STD.DEV.  CARGO  TARDINESS  =  8.95 

MEAN  WEIGHTED  CARGO  TARDINESS  =  69466 

STD.DEV.  WEIGHTED  CARGO  TARDINESS  =  119910 

PERCENT  CARGOES  DELIVERED  ON-TIME  >=  35.00  % 

PERCENT  CARGOES  DELIVERED  LATE  '  60.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  75.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES  ■=  20. OO  % 

PERCENT  UNDELIVERED  CARGOES  =  5 . OO  % 


Table  4.2(c) 
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PERCENT  TONS  DELIVERED  ON-TIME        =       10.84  % 
PERCENT  TONS  DELIVERED  LATE  =       16.26  % 

PERCENT  TONS  UNDELIVERED  =       72.90  % 


SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY  =  1.31 

MEAN  WEIGHTED  ROUTE  CIRCUITRY  =  1.24 

MEAN  SHIP  UTILIZATION  =  11.93  % 

MEAN  DISTANCE  TRAVELED  =  34585 

STD.DEV.  OF  DISTANCE  TRAVELED  =  80O2 

MEAN  TON-MILES  =  2.21E+08 

STD.DEV.  OF  TON-MILES  =  1.42E+08 

MEAN  SHIPPING  DISTANCE  =  8839 

MEAN  PORT  DELAY  PER  STOP  =  1.250 

STD.DEV.  OF  PORT  DELAY  PER  STOP  =  5.013 

MEAN  PORT  DELAY  PER  SHIP  =  9.286 

STD.DEV.  OF  PORT  DELAY  PER  SHIP  =  11.250 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT   =  11.84  % 

MEAN  ROUTE  TIME  =  78.43 

STD.DEV.  OF  ROUTE  TIME  =  16.76 
R;  T=3.24/4.71  14:05:20 
SSTOP 


Table  4.2(d) 
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»»»»•••»»•«•*••••«•••«»**••••***•••*»••••****••••*•••♦** 

SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS 
STO.DEV.  CARGO  TARDINESS 
MEAN  WEIGHTED  CARGO  TARDINESS 
STO.DEV.  WEIGHTED  CARGO  TARDINESS 
PERCENT  CARGOES  DELIVERED  ON-TIME 
PERCENT  CARGOES  DELIVERED  LATE 
PERCENT  COMPLETELY  DELIVERED  CARGOES  = 
PERCENT  PARTIALLY  DELIVERED  CARGOES   = 
PERCENT  UNDELIVERED  CARGOES 
PERCENT  TONS  DELIVERED  ON-TIME 
PERCENT  TONS  DELIVERED  LATE 
PERCENT  TONS  UNDELIVERED  « 


5. 

90 

8. 

03 

35697 

6627  1 

50. 

00  % 

45, 

,00  % 

85, 

,00  % 

10 

,00  % 

5 

.00  % 

47 

.75  % 

34 

.72  % 

17 

.53  % 

*«*******4 


>•••**•••••< 


,»»»..».•»••••••••••••»*••••••»»••*•*•* 


■*»«*»»*«»••••*«**••••»»••••••*•** 


SUMMARY  OF  SHIP  STATISTICS 


MEAN  ROUTE  CIRCUITRY 

MEAN  WEIGHTED  ROUTE  CIRCUITRY 

MEAN  SHIP  UTILIZATION 

MEAN  DISTANCE  TRAVELED 

STO.DEV.  OF  DISTANCE  TRAVELED 

MEAN  TON-MILES 

STO.DEV.  OF  TON-MILES 

MEAN  SHIPPING  DISTANCE 

MEAN  PORT  DELAY  PER  STOP 

STD.DEV.  OF  PORT  DELAY  PER 

MEAN  PORT  DELAY  PER  SHIP 

STD.DEV.  OF  PORT  DELAY  PER 

MEAN  PERCENT  OF  TIME  SPENT 

MEAN  ROUTE  TIME 

STD.DEV.  OF  ROUTE  TIME 

R;  T=2.08/2.95  12: 1 3 : 04 

SSTOP 


= 

0.89 

RY 

= 

0.82 

= 

2.87  : 

= 

21985 

ED 

= 

9001 

e 

1  .34E  +  08 

= 

1  .04E+08 

= 

7653 

= 

4.  167 

STOP 

= 

12.980 

= 

25.000 

SHIP 

= 

23.317 

IN  PORT 

= 

45.34  ' 

= 

55.  14 

= 

26.09 

Table  4.3:7  Ships,  Data  Set  B 
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SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS                   =  5.45 

STD.DEV.  CARGO  TARDINESS               =  8.10 

MEAN  WEIGHTED  CARGO  TARDINESS         =  34423 

STD.DEV.  WEIGHTED  CARGO  TARDINESS     =  80202 

PERCENT  CARGOES  DELIVERED  ON-TIME     =  60.00  % 

PERCENT  CARGOES  DELIVERED  LATE         =  40.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  90.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES   =  10.00  % 

PERCENT  UNDELIVERED  CARGOES            =  0.0  % 

PERCENT  TONS  DELIVERED  ON-TIME        =  49.43  % 

PERCENT  TONS  DELIVERED  LATE           =  32.10  % 

PERCENT  TONS  UNDELIVERED               =  18.47  % 

******************************************************** 


(♦A***************************************** 

SUMMARY  OF  SHIP  STATISTICS 


MEAN  ROUTE  CIRCUITRY  =  1.19 

MEAN  WEIGHTED  ROUTE  CIRCUITRY  =  1.26 

MEAN  SHIP  UTILIZATION  =  4.68  % 

MEAN  DISTANCE  TRAVELED  =  27878 

STD.DEV.  OF  DISTANCE  TRAVELED  =  10007 

MEAN  TON-MILES  =  1.79E+08 

STD.DEV.  OF  TON-MILES  =  1.11E+08 

MEAN  SHIPPING  DISTANCE  =  10313 

MEAN  PORT  DELAY  PER  STOP  =  1.881 

STD.DEV.  OF  PORT  DELAY  PER  STOP       =  5.460 

MEAN  PORT  DELAY  PER  SHIP  =  11.286 

STD.DEV.  OF  PORT  DELAY  PER  SHIP       =  8.939 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT   =  18.46  % 

MEAN  ROUTE  TIME  =  61.14 

STD.DEV.  OF  ROUTE  TIME  =  18.80 
R:  T.2. 15/3.01  12:15:55 
SSTOP 


Table  4.4:  7  Ships,  Data  Set  B 
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SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  =  5.35 

STD.DEV.  CARGO  TARDINESS  =  7.95 

MEAN  WEIGHTED  CARGO  TARDINESS  =  36515 

STD.DEV.  WEIGHTED  CARGO  TARDINESS  =  75687 

PERCENT  CARGOES  DELIVERED  ON-TIME  =  55.00  % 

PERCENT  CARGOES  DELIVERED  LATE  =  45.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  90.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES  =  10.00  % 

PERCENT  UNDELIVERED  CARGOES  =  0.0  % 

PERCENT  TONS  DELIVERED  ON-TIME  =  48.23  % 

PERCENT  TONS  DELIVERED  LATE  =  42.82  % 

PERCENT  TONS  UNDELIVERED  =  8.96  % 


SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY 

MEAN  WEIGHTED  ROUTE  CIRCUITRY 

MEAN  SHIP  UTILIZATION 

MEAN  DISTANCE  TRAVELED 

STD.DEV.  OF  DISTANCE  TRAVELED 

MEAN  TON-MILES 

STD.DEV.  OF  TON-MILES 

MEAN  SHIPPING  DISTANCE 

MEAN  PORT  DELAY  PER  STOP 

STD.DEV.  OF  PORT  DELAY  PER  STOP 

MEAN  PORT  DELAY  PER  SHIP 

STD.DEV.  OF  PORT  DELAY  PER  SHIP 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT 

MEAN  ROUTE  TIME 

STD.DEV.  OF  ROUTE  TIME 

R;  T-2.  11/2.98  12;  18:32 

SSTOP 


1. 

.  13 

1. 

,  14 

6, 

,80  % 

28464 

8105 

1  .90E  +  08 

8.80E+07 

9810 

1  , 

.682 

4 

.850 

10 

.571 

7 

.678 

17 

.66  % 

59 

.86 

12 

.92 

Table  4.5:  7  Ships,  Data  Set  B 
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8 

,55 

13, 

.22 

51941 

97347 

50 

.00  % 

40 

.00  % 

75, 

.00  % 

15, 

.00  % 

10, 

.00  % 

33, 

.4  1  % 

34 

.44  % 

32 

.  15  % 

SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS 
STD.DEV.  CARGO  TARDINESS 
MEAN  WEIGHTED  CARGO  TARDINESS 
STD.DEV.  WEIGHTED  CARGO  TARDINESS 
PERCENT  CARGOES  DELIVERED  ON-TIME 
PERCENT  CARGOES  DELIVERED  LATE 
PERCENT  COMPLETELY  DELIVERED  CARGOES  = 
PERCENT  PARTIALLY  DELIVERED  CARGOES   = 
PERCENT  UNDELIVERED  CARGOES 
PERCENT  TONS  DELIVERED  ON-TIME 
PERCENT  TONS  DELIVERED  LATE 
PERCENT  TONS  UNDELIVERED 

SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY  =  1.00 

MEAN  WEIGHTED  ROUTE  CIRCUITRY  =  1.12 

MEAN  SHIP  UTILIZATION  =  11.47  % 

MEAN  DISTANCE  TRAVELED  =  29784 

STD.DEV.  OF  DISTANCE  TRAVELED  =  8447 

MEAN  TON-MILES  =  2.00E+08 

STD.DEV.  OF  TON-MILES  =  1.15E+08 

MEAN  SHIPPING  DISTANCE  =  9885 

MEAN  PORT  DELAY  PER  STOP  =  1.158 

STD.DEV.  OF  PORT  DELAY  PER  STOP      =  3.796 

MEAN  PORT  DELAY  PER  SHIP  =  8.800 

STD.DEV.  OF  PORT  DELAY  PER  SHIP      =  7.014 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT   =  12.43  % 

MEAN  ROUTE  TIME  =  70.80 

STD.DEV.  OF  ROUTE  TIME  =  21.57 
R;  T. 2. 57/3. 68  12:10:29 


Table  4.6:  5  Ships,  Data  Set  B 
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SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  =  11.65 

STD.DEV.  CARGO  TARDINESS  =  16.67 

MEAN  WEIGHTED  CARGO  TARDINESS  =  73126 

STD.DEV.  WEIGHTED  CARGO  TARDINESS  =  106733 

PERCENT  CARGOES  DELIVERED  ON-TIME  =  30.00  % 

PERCENT  CARGOES  DELIVERED  LATE  =  55.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  75.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES  =  10.00  % 

PERCENT  UNDELIVERED  CARGOES  =  15.00  % 

PERCENT  TONS  DELIVERED  ON-TIME  =  20.76  % 

PERCENT  TONS  DELIVERED  LATE  =  57 . 2 1  % 

PERCENT  TONS  UNDELIVERED  =  22.03  % 

SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY 

MEAN  WEIGHTED  ROUTE  CIRCUITRY 

MEAN  SHIP  UTILIZATION 

MEAN  DISTANCE  TRAVELED 

STD.DEV.  OF  DISTANCE  TRAVELED 

MEAN  TON-MILES 

STD.DEV.  OF  TON-MILES 

MEAN  SHIPPING  DISTANCE 

MEAN  PORT  DELAY  PER  STOP 

STD.DEV.  OF  PORT  DELAY  PER  STOP 

MEAN  PORT  DELAY  PER  SHIP 

STD.DEV.  OF  PORT  DELAY  PER  SHIP 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT 

MEAN  ROUTE  TIME 

STD.DEV.  OF  ROUTE  TIME 

R:  T-2.66/3.90  13:06:33 

SSTOP 


1  . 

1  1 

1  . 

12 

10. 

80  % 

31630 

12247 

2 

. 15E+08 

9 

.46E+07 

9235 

1  . 

237 

4  . 

444 

9. 

400 

9. 

,317 

12. 

,53  % 

75. 

,00 

32. 

,26 

Table  4.7:  5  Ships,  Data  Set  B 
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SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  =  3.40 

STD.DEV.  CARGO  TARDINESS  =  5.70 

MEAN  WEIGHTED  CARGO  TARDINESS  =  14240 

STD.DEV.  WEIGHTED  CARGO  TARDINESS  =  26227 

PERCENT  CARGOES  DELIVERED  ON-TIME  =  45. GO  % 

PERCENT  CARGOES  DELIVERED  LATE  =  35.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  70.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES  =  10.00  % 

PERCENT  UNDELIVERED  CARGOES  =  20.00  % 

PERCENT  TONS  DELIVERED  ON-TIME  =  24.15  % 

PERCENT  TONS  DELIVERED  LATE  =  33.91  % 

PERCENT  TONS  UNDELIVERED  =  41.95  % 


•*••*♦*♦*•*•*♦*•••••••»*•**••***•**•••••***♦•♦♦•*••*•*•* 

SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY  =  0.99 

MEAN  WEIGHTED  ROUTE  CIRCUITRY  »  1.17 

MEAN  SHIP  UTILIZATION  =  9.62  % 

MEAN  DISTANCE  TRAVELED  =  24569 

STD.DEV.  OF  DISTANCE  TRAVELED  =  10590 

MEAN  TON-MILES  =  1.53E+08 

STD.DEV.  OF  TON-MILES  =  4.77E+07 

MEAN  SHIPPING  DISTANCE  =  8815 

MEAN  PORT  DELAY  PER  STOP  =  1.500 

STD.DEV.  OF  PORT  DELAY  PER  STOP  =  5.218 

MEAN  PORT  DELAY  PER  SHIP  =  10.200 

STD.DEV.  OF  PORT  DELAY  PER  SHIP  =  10.663 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT  =  17.17  % 

MEAN  ROUTE  TIME  =  59.40 

STD.DEV.  OF  ROUTE  TIME          •  =  27.10 
R;  T-2.55/3.74  13:09:23 
SSTOP 


Table  4.8:   5  Ships,  Data  Set  B 
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dropped  by  more  than  13%.     This  indicated  that  the  scheduling  constraints 
were  too  tight  for  such  a  small  number  of  ships  to  handle  with  reasonable 
ship  utilization.     We  therefore  further  refined  the  cargo  sizes,  as 
indicated  in  Column  C,  Table  4.1,   to  form  Data  Set  C.     In  this  data  set  no 
cargoes  require  multiple  ship- trips. 

Summary  statistics  from  this  third  data  set  appear  in  Tables  4.9, 
4.10  and  4.11.     They  show  a  substantial  improvement  in  performance  for  the 
5-shipcase.     In  the  best  of  three  seed-cargo  configurations,   96%  of  the 
tons  and  95%  of  the  cargoes  are  delivered.     For  this  case  ship  utilization 
is  6.2%,   indicating  many  more  cargoes  could  be  transported  with  appropriate 
scheduling  requirements.     In  addition,  the  percentage  of  on-time  delivered 
cargoes  hovered  around  the  40%  level,  which  is  relatively  lew.     We  opted 
not  to  try  seven-ships  of  this  case  because  of  the  already-lav  ship 
utilization. 

A  closer  look  at  the  schedules  associated  with  the  above  runs 
reveals  several  interesting  observaticxis.     Take  for  instance  ship  #  6  of 
run  #  1   (displayed  in  Table  4.2).     This  ship  picks  up  cargo  #  6  from 
Charlestcn,  S.C.  on  day  25  and  delivers  that  cargo  in  Malaysia  en  day  47. 
It  subsequently  travels  en  ballast  to  Okinawa  where  on  day  57   it  loads 
three  cargoes:     Cargo  #  17,  and  parts  of  cargoes  #  15  and  #  16,  both  of 
which  are  large-size  ard  have  to  be  split.     Cargo  #  15  is  split  in  two, 
10,850  tons  carried  by  the  above  ship  (#6),  and  13,800  tons  carried  by  ship 
#  5  several  days  later   (see  also  Table  4.2).     Cargo  #  16  is  carried 
entirely  by  ship  #  6,  but  in  four   (4)   rountrips   (Okinawa  to  Malaysia), 
because  of  its  even  larger  size   (51,880  tons,  compared  to  a  capacity  of 
19,125  tons  for  ship  #6) .     Ship  #  6  completes  its  trip  on  day  88,  after 
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SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  =  8.45 

STD.DEV.  CARGO  TARDINESS  =  8.77 

MEAN  WEIGHTED  CARGO  TARDINESS  =  53377 

STD.DEV.  WEIGHTED  CARGO  TARDINESS  =  9005  1 

PERCENT  CARGOES  DELIVERED  ON-TIME  =  30.00  % 

PERCENT  CARGOES  DELIVERED  LATE  =  70.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  95.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES  =  5.00  % 

PERCENT  UNDELIVERED  CARGOES  •  0.0  % 

PERCENT  TONS  DELIVERED  ON-TIME  =  21.12  % 

PERCENT  TONS  DELIVERED  LATE  »  69.30  % 

PERCENT  TONS  UNDELIVERED  =  9.59  % 


******************************************************** 

SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY 

MEAN  WEIGHTED  ROUTE  CIRCUITRY 

MEAN  SHIP  UTILIZATION 

MEAN  DISTANCE  TRAVELED 

STD.DEV.  OF  DISTANCE  TRAVELED 

MEAN  TON-MILES 

STD.DEV.  OF  TON-MILES 

MEAN  SHIPPING  DISTANCE 

MEAN  PORT  DELAY  PER  STOP 

STD.DEV.  OF  PORT  DELAY  PER  STOP 

MEAN  PORT  DELAY  PER  SHIP 

STD.DEV.  OF  PORT  DELAY  PER  SHIP 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT 

MEAN  ROUTE  TIME 

STD.DEV.  OF  ROUTE  TIME 

R;  T-2.45/3.53  13:19:05 

SSIOP 


0, 

.98 

O 

,87 

1 . 

.80  % 

306  16 

9769 

1  .62E  +  08 

8.29E-t-07 

7513 

0 

.667 

4. 

.  165 

5 

.600 

1  1 

.971 

7 

.53  % 

74 

.40 

24 

.32 

Table  4.9:   5  Ships,  Data  Set  C 
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SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  =  11.00 

STD.DEV.  CARGO  TARDINESS  =  19.34 

MEAN  WEIGHTED  CARGO  TARDINESS  =    83080 

STD.DEV.  WEIGHTED  CARGO  TARDINESS  =   175713 

PERCENT  CARGOES  DELIVERED  ON-TIME  =  45.00  % 

PERCENT  CARGOES  DELIVERED  LATE  =  50.00  % 

PERCENT  COMPLETELY  DELIVERED  CARGOES  =  95.00  % 

PERCENT  PARTIALLY  DELIVERED  CARGOES  =  0.0  % 

PERCENT  UNDELIVERED  CARGOES  =  5.00  % 

PERCENT  TONS  DELIVERED  ON-TIME  =  30.21  % 

PERCENT  TONS  DELIVERED  LATE  =  65.74  % 

PERCENT  TONS  UNDELIVERED  =  4.05  % 


************* 


,*******************************»********** 


******************************************************** 

SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY  =  1.15 

MEAN  WEIGHTED  ROUTE  CIRCUITRY  =  1.06 

MEAN  SHIP  UTILIZATION  =  6.18  % 

MEAN  DISTANCE  TRAVELED  =  35109 

STD.DEV.  OF  DISTANCE  TRAVELED  =  15253 

MEAN  TON-MILES  =  2.20E+08 

STD.DEV.  OF  TON-MILES  =  1.20E+08 

MEAN  SHIPPING  DISTANCE  =  9607 

MEAN  PORT  DElAY  PER  STOP  =  1.100 

STD.DEV.  OF  PORT  DELAY  PER  STOP  =  3.529 

MEAN  PORT  DELAY  PER  SHIP  =  8.800 

STD.DEV.  OF  PORT  DELAY  PER  SHIP  =  6.058 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT  =  10.81  % 

MEAN  ROUTE  TIME  =  8 1 . 40 

STD.DEV.  OF  ROUTE  TIME  =  36.77 
R;  T-2.34/3.38  13:22:33 
SSTOP 


Table  4.10:   5  Ships,  Data  Set  C 
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9 

.00 

14 

.76 

48146 

90576 

45, 

.00  % 

45 

.00  7. 

85 

.OO  % 

5, 

.00  % 

10 

.00  % 

34, 

.95  % 

48 

,89  % 

16, 

,16  % 

SUMMARY  OF  CARGO  STATISTICS 

MEAN  CARGO  TARDINESS  = 

STD.DEV.  CARGO  TARDINESS 
MEAN  WEIGHTED  CARGO  TARDINESS 
STD.DEV.  WEIGHTED  CARGO  TARDINESS 
PERCENT  CARGOES  DELIVERED  ON-TIME 
PERCENT  CARGOES  DELIVERED  LATE 
PERCENT  COMPLETELY  DELIVERED  CARGOES  = 
PERCENT  PARTIALLY  DELIVERED  CARGOES   = 
PERCENT  UNDELIVERED  CARGOES 
PERCENT  TONS  DELIVERED  ON-TIME 
PERCENT  TONS  DELIVERED  LATE 
PERCENT  TONS  UNDELIVERED 


SUMMARY  OF  SHIP  STATISTICS 

MEAN  ROUTE  CIRCUITRY  =  0.99 

MEAN  WEIGHTED  ROUTE  CIRCUITRY  =  1.12 

MEAN  SHIP  UTILIZATION  =  12.54  % 

MEAN  DISTANCE  TRAVELED  =  29644 

STD.DEV.  OF  DISTANCE  TRAVELED  =  9223 

MEAN  TON-MILES  =  1.96E+08 

STD.DEV.  OF  TON-MILES  =  9.84E+07 

MEAN  SHIPPING  DISTANCE  =  9807 

MEAN  PORT  DELAY  PER  STOP  =  2.105 

STD.DEV.  OF  PORT  DELAY  PER  STOP  =  8.036 

MEAN  PORT  DELAY  PER  SHIP  =  16.000 

STD.DEV.  OF  PORT  DELAY  PER  SHIP  =  17.875 

MEAN  PERCENT  OF  TIME  SPENT  IN  PORT   =  22.10  % 

MEAN  ROUTE  TIME  =  72.40 

STD.DEV.  OF  ROUTE  TIME  =  26.43 
R;  T=2.46/3.55  13:24: 19 
SSTOP 


Table  4.11:   5  Ships,  Data  Set  C 
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making  these  four  roundtrips  from  Okinawa  to  Malaysia.  Notice  that  this 
ship  travels  from  the  East  Coast  of  the  U.S.  to  the  Pacific  practically 
empty,  since  cargo  #6  is  cnly  30  tons.  This  is  due  to  the  fact  that  cargo 
#  6  was  assigned  arbitrarily  to  ship  #  6  as  a  seed  assignment  by  the  user, 
ar»3  that  no  other  cargoes  were  assigned  to  travel  on  the  same  ship  on  its 
way  to  the  Pacific  because  of  incompatible  schedules. 

Similar  interesting  schedule  patterns  were  observed  in  other  runs 
of  MDRSS. 

In  the  rest  of  this  section  we  further  analyze  the  performance  of 
MORSS  based  on  the  results  of  the  previous  discussion.  First,  it  is 
evident  that  the  performance  of  the  system  depends  highly  on  the  particular 
data  set  being  used.  Much  of  the  discussion  in  the  first  part  of  this 
section  focused  on  tailoring  the  data  set  to  a  small  fleet  size.  It  is 
unclear  what  the  a  priori  limits  for  feasibility  are.  For  example,  cargoes 
#2  and  #9  seem  to  be  "difficult"  cargoes  in  the  sense  that  they  are  often 
at  least  partially  unscheduled.  Many  factors  are  involved.  Boundary 
caiditicHis,  cargo  size,  seed  selection  and  interactions  between  large 
cargoes  may  account  for  much  of  the  difficulty.  In  addition,  the 
parameters  involved  in  the  utility  functions  need  detailed  calibraticxi 
themselves  (see  also  Chapter  5) . 

To  aid  in  the  analysis  of  the  runs,  MCRSS  computed  a  large  variety 
of  statistics  at  the  end  of  each  run.  The  most  important  cxies  are 
summarized  in  Table  4.12,  for  each  of  the  runs.  These  statistics  are  the 
measures  by  which  we  evaluated  the  performance  of  the  system.  The  most 
important  of  the  cargo  statistics  are  the  percentages  of  cargoes 
(delivered)  on  time  and  tons  (delivered)  on  time.  These  most  clearly 
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reflect  the  primary  concern  of  the  MSC  to  deliver  cargoes  en  time. 

Among  the  ship-related  statistics,  route  circuity,  ship  utilization 
ana  percent  of  time  spent  in  port  are  the  most  important.  By  "route 
circuity"  we  mean  the  ratio  of  the  total  distance  traveled  by  a  ship 
divided  hy  the  sum  of  POE-POD  distances  for  all  cargoes  carried  by  the 
ship.  Thus,  a  low  circuity  (less  than  half)  means  the  ship  carries  many 
cargoes  most  of  the  time,  while  a  high  circuity  (more  than  1.5)  means  the 
ship  carries  few  cargoes  at  a  time,  and  is  deadheading  a  good  part  of  the 
time  also.  These  measures  are  important  as  indications  of  the  efficiency 
at  which  the  system  operates. 

We  now  turn  to  a  discussion  of  the  correlation  betweei  the 
statistics  generated  by  MORSS.  Plots  of  some  of  these  aj^ar  in  Figures 
4.3  to  4.6.  From  Figures  4.5  and  4.6  we  see  that  ship  utilization  and  the 
percentage  of  tons  delivered  are  not  correlated  with  the  percentage  of  tons 
delivered  en  time.  Figure  4.3  shows  a  strong  linear  correlation  between 
the  percentage  of  on-time  cargoes  and  tons.  Figure  4.4  indicates  the 
percentage  of  cargoes  en  time  is  close  to  being  independent  of  the 
percentage  delivered.  These  preliminary  results  indicate  that  ship 
utilization  is  not  a  good  performance  measure  for  problems  with  tight  or 
infeasible  scheduling  requirements.  This  result  will  be  checked  more 
closely  with  a  larger  feasible  set  of  cargo  movement  requirements  during 
the  calibration  procedure. 

We  propose  several  bounds  on  system  performance.  First,  ship 
utilization  has  a  maximum  of  the  order  of  50%  with  the  given  POE-POD 
structure.  This  is  because  of  traveling  on  ballast  from  PCXD  to  PCE. 
Practically  speaking,  this  bound  is  not  achievable  either,  because  of  the 
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necessity  of  multiple  cargoes  on  the  same  ship.  In  this  case  the  ship  is 
not  full  between  c3eliveries.  Second,  route  circuity  has  a  maximum  of  2.0, 
corresponding  to  the  case  where  a  ship  carries  only  one  cargo  at  a  time. 
Both  of  these  quantities  are  bounded  telow  by  zero.  Third,  each  data-set 
has  its  own  particular  structure.  In  many  cases  this  results  in  bounds  on 
the  number  of  cargoes  or  tons  that  can  be  delivered  on  time. 

Given  these  bounds,  it  is  worthwhile  to  note  that  the  best  ship 
utilization  achieved  in  these  runs  had  a  value  of  12.54%  (in  run  #  10). 
This  means  that  the  ships  in  that  sealift  problem  instance  averaged  about 
25%  full  while  transporting  cargo.  This  is  a  reasonable  performance  for 
such  a  tight  problem,  where  the  average  late  cargo  v^s  9  days  overdue. 
This  points  out  the  difficulty  in  establishing  norms  for  the  expected 
performance  of  the  system  under  MORSS  or  any  scheduling  algorithm.  This 
issue  will  be  further  explored  in  a  continuing  phase  of  the  project  (see 
also  Chapter  5) . 
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CHAPTER  5 
CONCLUDING  REMARKS 

5.1  Introduction 

This  chapter  provides  some  additional  details  on  miscellaneous 
other  activities  related  to  this  project  (section  5.2)  and  concludes  by 
describing  directions  for  further  research  on  the  MSC  operational  problem 
(section  5.3). 

5.2  Other  Project-Related  Written  Products 

There  have  been  several  additional  self-contained  products,  written 
by  members  of  the  MIT  project  team,  and  related  to  this  project.  These 
include  an  annotated  bibliography,  -  by  Thompson  (1983)  -,  twD  M.Sc. 
theses,  -  by  Badjis  (1982)  and  Jeng  (1984),  and  a  PhD  thesis,  -  by  Kim 
(1985) . 

In  Thompson  (1983) ,  a  bibliography  of  about  70  references  in  this 
general  problem  area  is  described.  This  bibliography  is  maintained  in  the 
MIT  project  library  and  updated  at  regular  time  intervals. 

The  M.Sc  thesis  of  Bard j is  (1982)  was  completed  a  few  months  before 
this  project  was  initiated,  and  hence  cannot  be  considered  an  "official" 
product  of  the  project.  However,  ws  include  it  here  because  to  our 
knowledge  it  was  the  first  attempt  to  look  into  the  MSC  operational  problem 
from  a  rigorous  analytical  standpoint.  The  thesis  developed  exact 
mathematical  programming  formulaticxis  for  a  spectrum  of  variants  of  the  MSC 
problem,  by  examining  a  variety  of  objective  functions,  oxistraints,  etc. 
Upon  initiation  of  the  project,  the  MIT  team  decided  not  to  use  an  exact 
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af^oach   (for  the  reasons  outlined  in  Chapter  2),   and  hence  these 
formulations  were  no  longer  pursued. 

The  M.Sc.   thesis  of  Jeng    (1984)    took  the  "sequential   insertion" 
algorithm  developed  by  Jaw  et  al   (1984)   for  the  nulti-vehicle  many-to-many 
advance -request  dial-a-ride  problem  with  time  windows,   and  attempted  to 
adapt  it  to  the  MSC  operational  problem.     As  described  in  Chapter  2,  the 
"sequential  inserticai"  algorithm  is  a  very  efficient  procedure  for 
scheduling  a  fleet  of  vehicles  in  a  dial-a-ride  environment,   and 
computational  experience  with  the  procedure  has  been  very  satisfactory. 
Jeng's  work  dealt  with  necessary  modif icatiwis  in  the  procedure  so  that  it 
could  be  applied  to  a  version  of  the  MSC  operational  problem.     A  generic 
computer -prog ram  was  written  to  that  effect,  but  was  never  implemented  en 
the  MSC-supplied  or  other  data. 

The  PhD  thesis  of  Kim   (1985)   shed  light  on  some  very  interesting 
theoretical  aspects  of  the  MSC  problem.     Specifically,   it  recognized  that 
in  the  absence  of  time  constraints   (EPT's,  EDT's  and  LDT's),   the  routing 
subproblem  of  the  MSC  problem  becomes  usually  very  easy  to  solve,  given 
that  ports  are  located  "alcng  the  shoreline".     Kim  them  defined  the 
"shoreline"  distance  metric  as  a  special  case  of  the  Euclidean  distance 
metric  and  imposed  time  constraints  en  the  problem.     He  then  developed  a 
class  of  heuristic   (approximate)   algorithms  for  the  single-ship  "shoreline" 
problem  with  time  ocMistraints,  and  derived  the  worst -case  performance  of 
these  algorithms  (in  terms  of  deviation  from  the  theoretical  optimum).     For 
the  special  case  in  which  all  ports  are  located  en  a  straight  line,   he 
showed  that  depending  en  the  objective  function  and  the  constraints  of  the 
problem,  the  problem  can  be  either  solved  exactly  by  a  "polynomial" 
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algorithm,  or  belongs  to  the  class  of  "NP-compLete"  problems  (for  v^ich  no 
polynomial  algorithm  is  known  to  exist.)     Kim's  work  has  opened  some  very 
interesting  directions  for  further  research  on  this  class  of  prolems. 

5.3  Conclusions  and  Directions  for  Further  Research 

We  conclude  the  main  body  of  the  report  with  our  conclusions  and 
cxar  ideas  on  directions  for  further  research  in  this  area. 

lb  our  knowledge,   today  the  MORSS  algorithm  represents  the  cnly 
methodology  that  has  been  designed  and  developed  specifically  for  the  MSC 
operational  routing  and  scheduling  prcfolem.     As  stated  in  the  project's 
statement  of  objectives  (see  Chapter  1),   the  MIT  team  set  forth  to 
investigate  a  class  of  sealift  routing  and  scheduling  problems,  develop, 
analyze  and  test  solution  algorithms  for  such  problems,  and  work  with  the 
MSC  and  others  so  as  to  increase  the  level  of  knowledge  of  these  problems. 
As  a  result  of  our  efforts  within  the  past  two  and  a  half  years,  we  feel 
that  progress  in  the  project  has  bean  in  accordance  with  the  above 
objectives  and  with  the  schedule  we  had  proposed  to  accomplish  them.     Not 
only  do  we  know  much  more  about  the  structure  and  complexity  of  this 
problem  now  than  we  did  vi^en  this  project  was  starting,   but  we  do  possess  a 
methodology  and  an  associated  computer  program  that  can  form  the  basis  for 
future  implementation  by  the  MSC.     We  also  feel  that  we  have  made  progress 
regarding  the  stated  longer-term  objectives  of  this  project,  that  is,  to 
develop  a  procedure  that  could  be  ultimately  implemented  by  the  MSC, 
enhance  the  state  of  the  art  in  the  solution  of  complex,  large-scale 
transportation  problems,  and  advance  the  state  of  knowledge  in  interactive 
user-frienaiy  algorithms.     In  fact,  we  feel  that  many  of  the  principles  and 
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methods  we  have  adopted  for  this  project  could  be  used  in  other 
environments  as  well. 

There  is  no  questicxi  that  our  invest ig at icai  to  date  has  left 
considerable  room  for  both  further  analysis  of  the  MSC  operational  problem 
and  algorithmic  development  of  MDRSS.  In  the  following  we  describe  a  set 
of  possible  follow -on  activities  which  we  consider  essential  for  further 
progress  in  this  area.  These  activities  would  build  upcn  the  work 
accomplished  to  date,  by  targeting  specific  issues  that  have  been  either 
addressed  only  superficially,  or  not  addressed  at  all  by  this  project  thus 
far.  We  should  emphasize  that  all  of  these  activities  intentionally  fall 
into  the  category  of  research,  creation  of  new  knowledge,  and  methodology 
development,  as  opposed  to  real -world  implementation  of  a  software  package 
(a  possible  exception  is  Task  6,  v^ich  addresses  implementation  issues  to 
some  extent. ) 

The  description  of  these  activities  goes  as  follows: 
Task  1;  Investigation  and  Caliberation  of  Alternative  Utility  Functions; 

Although  considerable  effort  has  been  already  spent  to  come  up  with 
utility  functional  forms  that  make  sense  for  this  problem,  it  is 
conceivable  that  other  classes  of  functions  could  be  used  so  as  to  (a) 
model  the  MSC  decision  process  more  realistically,  (b)  decrease  the 
required  computational  effort  and  (c)  achieve  improved  solutions.  It  is 
clear  that  such  a  task  would  involve  an  increased  degree  of  interaction 
with  MSC  personnel,  so  as  to  incorporate  their  suggesticsis  and  other 
feedback  into  the  algorithm.  By  "calibration"  we  mean  the  determination  of 
the  most  appropriate  values  of  the  parameters  of  those  utility  functions. 
Since  those  values  are  user -inputs,  interaction  with  the  MSC  is  essential 
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here too. 

Task  2;  Investigation  of  Cargo  Assignment  Interactions;  M3RSS  currently 
assigns  utilities  to  potential  cargo-ship  assignment  pairs  without  taking 
into  account  possible  interactions  of  unassigned  cargoes  with  one  another. 
Thus,  it  is  conceivable  that  while  each  of  cargoes  i  and  j  is  by  itself  a 
good  assignment  for  ship  k,  assigning  both  of  them  to  the  same  ship  is  not. 
MCFSS  currently  handles  this  problem  by  (a)  limiting  the  number  of 
tentative  cargo  assignments  simultaneously  made  to  a  ship  at  each 
iteration,  and  (b)  by  "deassigning"  those  cargoes  from  a  ship's  list  of 
tentative  assignments  that  do  not  interact  well.  This  task  would 
investigate  other,  computationally  more  efficient  methods  for  taking  such 
possible  interactions  into  account.  Possible  approaches  in  this  context 
include  the  development  of  a  "pre-opt"  procedure  which  would  eliminate 
unlikely  arcs  in  the  transportation  network,  and/or  the  ccsistruction  of  a 
"swapper,  post -opt"  heuristic  vrtiich  would  eliminate  poor  combinations  of 
cargoes  once  the  assignments  are  made. 

Task  3;  Development  of  More  Sophisticated  Seed  Selection  Methods;  Seed 
selection  is  considered  to  be  an  important  step  in  MORSS,  The  current 
procedure  accomplishes  such  selection  by  solving  a  one-to-one  assignment 
problem  involving  ship  and  cargo  pairs  whose  utilities  have  be&n  computed. 
We  wDuld  like  to  explore  and  test  alternative  seed  selection  methods. 
Those  might  include  selecting  seeds  so  as  to  maximize  some  measure  of 
"spread-out-edness",  a  measure  which,  by  definition,  involves  interacticai 
anong  seed  cargoes.  A  subtask  here  might  ccnsist  of  developing  more 
advanced  aggregation/clustering  methods  to  facilitate  the  seed  selection 
process.  Finally,  we  would  like  to  investigate  the  sensitivity  of the 
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overall  schedule  to  seed  selection  rules. 

Task  4:  Modeling  of  CXieueing  Effects  at  Ports;  Ship  queue ing  at  ports 
during  periods  of  caigestion  is  likely  to  be  a  very  significant  issue 
during  the  actual  execution  of  the  schedule.  MCRSS  currently  includes  a 
term  in  the  utility  function  that  "measures"  port  congestion,  but  it  is 
clear  that  this  problem  merits  a  far  more  extensive  investigation.  We 
propose  to  develop  methods  that  predict  future  queueing  effects  at  ports 
more  accurately.  We  anticipate  that  in  doing  so  we  shall  need  more 
accurate  information  regarding  the  structure  of  ports  and  their  throughpjt 
as  a  function  of  demand  rate.  This  analysis  will  move  away  from  the 
essentially  deterministic  approach  that  has  been  used  so  far,  to  the 
modeling  of  probabilistic  effects.  "Optimal"  load ing/unloading/queue ing 
disciplines  would  be  investigated  so  as  to  improve  port  utilization  and 
reduce  overall  delays. 

Task  5:  Sensitivity  Analysis:  Other  than  user -specif ied  parameters 
calibration,  we  would  like  to  perform  sensitivity  analysis  on  many 
impOTtant  categories  of  the  input  data,  and  answer  "what  if"  questions  that 
would  help  obtain  further  insights  into  this  problem.  Such  data  include 
due  dates  for  cargoes  (i.e.,  "what  if  the  due  date  for  this  cargo  is  moved 
backward  by  one  day?",  "what  if  the  NATO-cc»itrolled  fleet  is  made 
available?",  etc. 

Task  6:  Further  Testing  of  Algorithm  and  User  Friendly  Implementation;  We 
would  like  to  further  develop  the  interactive  portion  of  MORSS.  This 
includes  the  capability  of  modifying  schedule  assignments,  add ing /removing 
ships  and  cargoes,  and  a  graphics  feature.  Our  plan  would  be  to  transfer 
MORSS  from  the  MIT  IBM  system  to  the  new  Apollo  color -graphics 
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microcomputer  at  the  Operations  Research  Center  (acquired  by  a  grant  from 
ONR) .  This  task  would  also  call  for  extensive  interaction  with  MSC  so  that 
the  ability  of  the  MSC  to  eventually  use  the  algorithm  is  maximized. 

At  the  time  of  the  writing  of  this  report,  the  MIT  team  is  engaged 
in  Tasks  1  and  6.  All  other  tasks  are  to  be  left  for  a  future  phase  of 
this  project. 
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APPENDIX  A 


DATA  STHKnURES 


A.l.  Introduction 

This  appendix  is  devoted  to  describing  the  data  structures  used  in  the 
MQf^S  algorithm.     The  MIT  team  spent  a  ccnsiderable  amount  of  effort  to  come 
up  with  a  data  structure  design  that  allows  for  fast  data  manipulation,  robust 
data  cross -referen:;e,  maximum  accessibility  for  the  interactive  user,  and  ease 
in  future  program  expansion.     We  found  the  use  of  PASCAL  very  useful  in  that 
respect   (computer  languages  such  as  FQE^TRAN  may  be  deficient  in  implementing 
this  type  of  data  structure  design) . 

The  data  structures  utilized  fall  into  4  major  categories:     Cbmplex 
Based,  Port  Based,  Cargo  Based,   and  Ship  Based.     These  structures  are 
(roughly)    interconnected  as  shown  in  Figure  A.l.     These  interconnections  are, 
in  fact,   two-way.     The  next  few  pages  elaborate  on  the  data  structures  and 
their  interconnections.     For  a  summary,   refer  to  charts  in  Figures  A. 2  and 
A. 3.     The  following  constants   (assumed  part  of  input,  contained  in  a  file)    are 
used  throughout: 
NIMMP     =     number  of  complexes 
MAXCRG     =     maximum  number  of  cargoes 
MAXSHP     =    maximum  number  of  ships 

IICUP      =    maximum  number  of  complexes  in  a  super -complex 
CNGPER     =     maximum  number  of   "congestion  periods". 
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A.2  Ports 

The  data  for  each  port  is  stored  in  a  record  type  UNIT.     Each  Unit 
contains  the  following  data: 
UNIT         =     RECORD 

NAME:     four  diaracters;  name  of  port 
DEPTH:      integer 
LENGTH:    integer 
BEAM:      integer 

NBRIH:      integer,   number  of  berths 
KIND:     character,  A,C,G,etc. 

The  ports  can  also  be  organized   into  arrays  of  up  to  7  units.     This  is 
so  because  all  complexes  contain  at  most  7  ports.     The  type  of  array  is  GRCUP. 
GROUP     =  ARRAY    (1..7)    of  UNIT 

A. 3  Ship  Stops 

For  each  ship  we  keep  a  linked  list  of  that  ship's  stops,  as  they 
occur  in  time.     A  stop  is  defined  as  one  pickup  or  delivery  stop  at  a  given 
port.     If  several  cargoes  are  picked  up  or  delivered  successively,  a  separate 
stop  is  constructed  for  each.     The  data  for  each  stop  is  contained  in  a  record 
of  type  EVENT,    pointed  to  by  a  pointer  of  type  LINKS: 
LINKS        =  +  EVENT 
EVENT       =     RECORD 

P-D:     character,  P  or  D  (pickup  car  delivery) 
CARGO:      integer,  code  of  cargo 

QUANT:      integer,  quantity  of  cargo  picked  up/delivered 
CMPL:      integer,  code  of  complex    (refer  to  Section  A. 4) 
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PORT:      integer,  ccx3e  of  pDrt  with  complex    (refer  to  Section  A. 4) 
DATEIN:      integer,  date  ship  finally  docks  at  PORT 
DATEOOT:      integer,   date  ship  finally  leaves  PORT 
WAITIN:      integer,  wait  before  docking  due  to  congestion 
WAITOUT:     integer,  wait  before  leaving  due  to  congestion 
SLACK:      integer,  wait  due  to  arrival  previous  to  EPT  or  EDT 
RMRTON:      integer,  masurement  tons  of  residual  capacity  after  stop 
RSHTON:      integer,  short  tons  of  residual  capacity  after  stop 
RSQFT:     integer,  square  feet  of  residual  capacity  after  stop 
NEXT:     links,   to  next  stop  in  schedule 
PREV:     links,   to  previous  stop  in  schedule 
MATCH:      linkS,   to  corresponding   pickup  or  delivery  of  same  cargo 

In  addition,   each  stop  is  also  addressable  from  the  corresponding  cargo 
record.     For  each  cargo  we  keep  a  local  linked  list  of  all  the 
pickups/deliveries  of  that  cargo.     Each  record  in  the  list  is  of  type  PCKUP 
and  is  pointed  to  by  pointers  of  type  LINK4. 
LINK4       =     PCKUP 
PCKUP       =     RECORD 
SHIPND:      integer,   number  of  ship 
EVNT:     Links,   to  pickup  in  SHIPNO's  schedule 
NXT:     to  next  record 

A. 4     Cargoes 

For  each  cargo  we  keep  a  record  of  type  MVT  pointed  to  by  pointers  of 
type  LINKl. 
LINKl       =tMVT 
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MVT  =     RECORD 

KEY:     integer,   code  assigned  to  cargo 
QRGCMP:      integer,  complex  of  origin  of  cargo 
DESCMP:      integer,  destination  complex  of  cargo 
ORGPRT:      integer,   origin  port  of  cargo 
DESPRT:      integer,  destination  port  of  cargo 
EPT:     integer 
EOT:      integer 

LOT:      integer 

MSP?IN:   integer,  measurement  tons  of  cargo 

SHKTN:   integer,  short  tons  of  cargo 

HVYLPT:   integer,  heavy  lift  code 

LOADED:  boolean,  TRJE  if  we  have  completely  loaded  cargo 

REM^R:   integer,  measument  tons  still  to  be  loaded 

RBMSHR:   integer,  short  tons  still  to  be  loaded 

REMSQ:   integer,  square  feet  still  to  be  loaded 

PFTYPE:   integer,  preferred  ship  type 

ATIMPT:   integer,  number  of  loading  attempts  for  cargo 

FSTLDNS:  link4,  points  to  1st  loading  in  local  list 

LSTLDNG:  link4,  points  to  last  loading  in  local  list 

The  overall  set  of  cargoes  is  kept  in  an  arrray  of  type  MTTPTR: 
MVTPTR  =  ARRAY  (1..MAXCRG)  OF  LIKNl 

Finally,  at  each  complex  we  keep  a  linked  list  of  the  cargoes  leaving 
from  the  complex.  The  records  are  of  type  CHS,  pointed  to  by  pointers  of  type 
LINK2. 
LINK2   =  +CRG 
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CRG  =     RBCCMD 

CCRR:      integer,   cxx3e  of  cargo   (=Key  in  MVT  record) 

POLL:  Link2,  next  cargo  in  list 

A. 5    Complexes 

The  data  for  each  complex  is  kept  in  a  record,  of  type  SE\7RL. 
SEVPL   =  FECORD 

CC»E:  5  characters,  name  of  complex  (i.e.  5EA.TB,  etc.) 
NPORTS:   integer,  number  of  ports 
PC5?rS:  GROUP,  (ports  at  compilex.  Section  A. 2) 
NCFG:   integer,  number  of  cargoes  leaving  from  complex 
FCR3:  LINK2,  first  cargo  is  linked  list  (Section  A. 3) 
LCR3:  LINK2,  last  cargo  in  linked  list 

CNGST:  Array  (1..CN3PER)  of  integer,  congestion  level  at  complex 
DIST:  Array  (1.  .NIICMP)  of  integers,  distances  to  all  other  complexes 
The  SEVRL  records  are  gathered  in  an  array  of  type  HUBS,  and  the 
supercomplexes  are  stored  in  records  of  type  AGGCXDMP;  themselves  arranged  in 
an  array  of  type  ALLAQGC. 
HUBS  =  ARRAY  (1. .NIM2MP)  of  SERVL 
AGGCCMP  =  RECORD 

N-COMP:  integer,  number  of  complexes 
INDEX:  Array  (1...INSUP)  of  integer  (indices  of  the  complexes 

as  they  appear  in  HUBS) 
ALLAQGC:   ARRAY  (1..NUMCMP)  of  AGGCOMP 
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A.6  Ships 

Each  ship's  data  is  kept  in  a  record  of  type  BOAT,   pointed  to  by  a 
pointer  of  type  LINKS 
LINKS       =     +BCIAT 
BOAT         =     raCCKD 

CODE:     integer,  code  assigned  to  ship 
SHPT:      integer,   ship  type 
DRAFT:      integer 
LN3TH:      integer 

BEEM:     integer,  beam  (deliberate  mispelling) 
BOCM:   integer 
SPEED:      integer 

MINCAP:    integer,  metric  ton  capacity 
STOCAP:      integer,   short  ton  capacity 
PTCAP:      integer,   square  feet  capacity 
FSTOP:     LINK3,   first  stop  in  schedule 
LSTOP:     LINK3,   last  stop  in  schedule 

NXTAV:     ARRAY   (1..2)   of   integer,  current  fully  loaded  period 
AVD:     ARRAY   (1.  .NUMCMP)   of   integer,   time  to  complex 
ID:     integer 
GRID:   integer 
NISC:     integer 
FLEET:      integer 
YEAR:      integer 
CRGUTIL:      integer,   utility  of  last  assignment 

The  pointers  to  the  ship  records  are  kept  in  an  array 
BOATPT  =  ARRAY    (1. .MAXSHD)    OF  LINKS 
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A.7    An  Illustration 

A  graphical  representation  of  cargoes  and  ships  data  structures 
appears  in  Figure  A. 2.  In  this  figure,  cargo  j  leaves  from  complex  0.  and 
goes  to  complex  D.   This  cargo  is  split  (totally)  between  ships  I  and  H. 

Similarly,  cargo  k  goes  from  0^^  to  D^  and  is  being  carried  -  only 
partially  -  by  ship  I. 

Ship  I's  only  stops  are  to  pick  up  and  deliver  parts  of  cargoes  j  and 
k.  A  graphical  representation  of  the  data  structures  for  complexes,  ports  and 
cargoes  appears  in  Figure  A. 3.  In  that  figure,  cargoes  j,  ^  j   j  and  j^  all 
leave  from  complex  I  and  from  ports  1,3,2,2,  respectively  at  complex  I. 


A. 8    Some  additional  data  structures  and  oommon  names  of  variables 

Durirq  a  run  of  the  optimization  algorithm  for  network  flows  (see 
Chapter  3  and  Appendix  B  for  further  details),  a  ship  may  be  assigned  at  most 
4  cargoes.   (4  could  be  changed  to  any  desired  constant) .  We  keep  track  of 
the  assignments,  for  a  given  ship,  in  records  of  type  PRSHP. 
PRSHP   =  FBCORD 
SMJM:  integer,  number  of  ships 

CNUMS:  ARRAY  (1..4)  of  integers,  cargoes  assigned  to  ship 
LOSTS:  ARRAY  (1..4)  of  integers,  costs  of  assignment 
PICKS:  ARRAY  (1..4)  of  LINK3,  pickups  of  assignment 
DELVS:  ARRAY  (1..4)  of  LINK3,  deliveries  of  assignment 
CCUtTT:  integer,  number  of  cargoes  actually  assigned  to  ship 

Constants:  NU  =  50 
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NV  =  50 

NU  and  NV  are  upper  bounds  on  t±ie  number  of  ships  and  cargoes, 
respectively,  in  a  given  time  window. 
ARRSHP  =  ARRAY  (1. .NU)  of  integer 
ARRCRG  =  ARRAY  (1. .NV)  of  integer 

Arrays  of  type  ARSHP  and  ARRCRG  will  carry  the  ships  and  cargoes  in  a 
given  time  window  respectively  (we  refer  to  these  arrays  as  cargostack  and 
shipstack) .  In  the  present  implementaticai,  the  array  of  ships  will  be 
constant  (i.e.  does  not  change  with  time  windows). 
BARRl  =  ARRAY  (1. .NU)  of  boolean 

After  the  optimizatioi  and  assignment/deassignment  in  a  time  window, 
BARRl (j)=false  if  cargo  j  in  cargostack  was  not  assigned.  This  is  used  in 
setting  up  the  next  time  window. 
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APPENDIX  B 


COMPUIER  PROGRAM  ORGANIZATION 


B.l    Introduction 

This  aj^ndix  is  devoted  to  giving  a  hierarchical  overview  of  the 
compater  prograjns  in  the  MC«SS  package.  This  description  does  not  include 
the  preprocessing  procedures,  which  (a)  scan  the  compiex  and  port  files  and 
create  a  single  file  containing  all  the  data,  and  (b)  lexicographically 
sort  the  cargoes  according  to   preferred  ship  type,  EPT,  EDT,  and  LDT. 

In  general,  the  data  is  set  up  to  match  the  needs  of  the  data 
structures  in  MJRSS    (see  Appendix  A).  Also,  the  very  top  program  is  a  CMS 
exec  called  SCHED  v^iich  sets  up  all  files  for  reading  and  writing  and 
actually  starts  MDRSS. 

Flow  charts  of  the  programs  and  subroutines  of  MORSS  are  shewn  in 
Figures  B.2  to  B.15.   (all  of  which  are  at  the  end  of  this  Appendix) .  Table  B.l 
provides  an  index  for  those  figures  and  Figure  B.l  displays  sane  of  the  conven- 
tions used  in  the  flowcharts.  A  description  of  the  arguments  of  each  sub- 
routine is  given  in  Appendix  C. 

Subroutines  that  merit  special  discussion  are  the  following: 

B.2     NBIWORK  Subroutine 

NETWORK  has  5  phases.     In  fhase  1  NETWORK  scans   (simultaneously) 
the  shipetack  and  the  cargostack   (as  those  were  defined  in  Aj^ndix  A) . 
For  each  cargo  and  ship  pair,   either  the  user  or  subroutine  ASSNUTIL  decide 
whether  they  are  compatible,   if  they  are,  vrfiat  the  utility  of  the 
assignment  is   (as  per  Chapter  3) .     If  the  pair  is  compatible  NETWORK  will 
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Program  or  Subroutine 


Figure 


Other  Subroutines  Called 


MORSS 

REZUDIN 

SEEDS 

SCHEDULE 

RLLTIME 

NETVORK 

PERMASSN 

ASSIGN 

UPD-P 

DWN-LOAD 

QUPD 

SHIFT 

UPD-T 

UPD-CRG 


B.2 

B.3 

B.4 

B.5 

B.6 

B.7.6 

B.8 

B.9 

B.IO 

B.ll 

B.12 

B.13.2 

B.14.2 

B.15 


READIN,  DISPLAY,  SEEDS,  SCHEDULE 

ASSIGN 

RLLTIME,  NETWDRK,  PERMASSN 

SHIFT,  EWN-LQAD 

PEEKER,  ASSNUTIL,  FLOSUB,  POSTOPT 

SHORT-SORT*,  ASSNUTIL,  ASSIGN 

UPD-P,  QUPD 

ADAPT*,  UPD-CRG,  INSERTS 


TABLE  B.l 


Index  of  MORSS  Program  and  Routines 
(* internal  routine,  not  described  here) 


-131- 


FLCWCHART  COWElvnTIONS 


XXX 


(DO  Loop: 
For  I:  =  1  to  N  DO 

XXX 

END 

NEXT  STATEMENT) 


WHILE 
CONDITION 

^ 

^-k 

(WHILE  Loop) 


(IF  Statenient) 


Figure  B.l 
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set  up  an  arc  corresponding     to  the  pair  . 

In  fhase  2  the  arc  data  is  consolidated  to  form  a  network   (a 
bipartite  graph)   described  by  a  forward -star  data  structure.     In  phases  1 
and  2  NETWORK  also  sets  up  a  "translaticai  table"  to  make  the  nodes  in  the 
grafh  correspond  to  cargo  and  ship  locations  in  the  respective  stacks. 

In  fhase  3,  the  network  data  structure  is  written  into  a  file. 

In  phase  4,  the  optimization  algorithm  (FLOSUB)    is  run.     This 
algorithm  prints  the  optimization  results  into  a  file   (in  general,  we  print 
the  data  into  files  for  run  control  -     in  the  ultimate  version  of  MORSS, 
arguments  should  be  passed  directly  between  programs.) 

Finally,   in  phase  5  subroutine  POSTOPT  reads  in  the  optimization 
results,   postprocesses  them,  and  returns  the  assignemnt  data  to  NETWCRK. 
In  spirit,  the  network   is  a  bipartite  graph   (U,V,E)   as  shown  in  Figure 
B.7.1,  v^ere  the  set  U  corresponds  to  ships  and  the  set  V  to  cargoes. 
NETWORK  sets  up  the  graph  so  that  every  ship  in  the  graph  is  connected  to 
at  least  one  cargo,   and  vice-versa.     Thus,   if  a  cargo  in  the  cargo  stack  is 
incompatible  with  all  ships,  that  cargo  will  not  ap^ar  in  the  network. 
Also,  the  graph  will  contain  a  node  correspcxiding  to  a  "dummy  ship"  and  a 
node  corresponding  to  a  "dummy  cargo"  to  pick  up  extra  supply  or  demand. 
Every  real  cargo  is  connected  bo  the  duinmyship  and  every  real  ship  is 
connected  to  the  dummy  cargo.     The  nodes  in  the  graph  are  labeled  by 
numbers  ranging  from  0  to  some  number  N+1,  v*iere  N=  number  of  real  ships  + 
number  of  real  cargoes.     0  represents  the  dummy  ship  and  N+1  the  dummy 
cargo. 

Example:  Number  of  real  ship6=2,     number  of  real  cargoes=3.      (see 
Figure  B.7.2). 


-133- 


A  forward-star  representation  of  the  grajh  is  used.     We  keep  the 
arrays: 

(arc  length)   HEAD:  heads     of  the  arcs 
(arc  length)   C3T:     cost  of  the  arcs  ordered  as  in  HEADS 
(ncde  length)   FIRST:    index  of  first  node    (in  HEAD)    that  node  is 
connected  to   (0  if  none) 

(node  length)  LAST:   index  of  last  node   (in  HEAD)   that  node  is 
connected  to   ( 0  if  none) 

(node  length)   RHS:   supply  of  node.     For  real  cargo  nodes,    it  is  -1. 
For   real  ship  nodes,  NETWORK  sets   it  at  4    (at  most  4  cargoes/ship)  .  The 
dummy     ship  can  have  any  RHS   (we  set  it  at  0)   and  the  dunmy  cargo  is  given 
enough  demand  to  balance  those  of  real  ship  and  cargo  nodes. 
We  also  keep 
NUMARCS:   total  number  of  arcs  in  graph  and  use 
SHIPS-IN-GRAPH:   number  of  real  ships  in  graph 
CARGO- IN -GRAPH:   number  of  real  cargo  in  graph 
Thus,   for  the  previous  example    (see  Fig.   8.. 7. 2)   we  have: 
HEAD  =  3,4,3,5,3,4,5 

CST     =  Large,  Large, x,x,x,x,x   (we  shall  talk  about  this  later) 
FIRSr=  1,3,5,0,0,0 
lAST  =  2,4,7,0,0,0 
RHS     =  0,3,3,-1,-1,-4 
Since  not  all  ships  or  cargoes  in  their  stacks  may  appear  in  the 
graph,  the  node  number  assigned  to  (say)   a  given  cargo  may  be  different 
from  that  cargo's  position  in  the  cargo  stack.     To  provide  translation,  we 
use  the  arrays  EQUIV  and  BACK.     Given  a     node  j>l,  EQUIV(j)   will  be  the 
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position  of 

'the  ship  corresponding  to  j,   if  j    £ SHIPS-IN-GRAPH 

the  cargo  corresponding  to  j ,   if  j    >  SHIPS-IN-GRAPH 


in  the  shipstack  car  cargostack,  respectively. 

For   instance,   if  SHIPS-IN-GRAPH  =  6  and  BQUIV(2)   =  4,   node  2  in  the 
graph  will  be  the  4th  ship  in  the  shipstack. 

BACK   is  the  inverse  function  of  EQUIV, 

As  mentioned  in  Appendix  A,   the  constants  NU   (=50)    and  NV   (=50)    are 
upper  bounds,   respectively,   to  the  number  of  ships  and  cargoes  in  their 
stacks.  NEIWCRK  initially  assumes  that  indeed  there  are  NU  ships  and  NV 
cargoes  in  the  graph.     Later  this  overestimate  is  corrected  and  in  the  same 
process  the  final  network  preresentation  is  obtained.  We  shall  refer  to 
this  process  as  the  "contraction".     The  initial  overestimate  is  also 
reflected   in  errays  EQUIV  and  BACK,   as  well  as  in  the  variable  MARK    (= 
number  of  arcs  in  graph)  .     Initially,  MARK  is  set  at  NV   (NEHWORK  assumes 
that  all  cargoes  are  in  the  graph,   so  node  0  -  the  dummy  ship-  is  connected 
to  NV  nodes.) 

In  order  bo  know,  at  any  point  before  the  contraction,  v^ich  ships 
and  cargoes  are  already  in  the  graph,  we  use  the  array  YES  of  boolean 
values.     For  i  l  NL 

YES(i)     =       T  if  i^  ship  in  shipstack  is  in  graph  yet 
F  otherwise 

Similarly,   for  1 1   j  1   NV 
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T  if  j       cargo  in  cargostack  is  in  graph  yet 
YES(j  +  NQ)   = 

F  otherwise 
YES  is  initialized  F  for  all  entries. 

The  main  work  done  before  the  contracticn  goes  as  follows:  We 
enumerate  the  shipstack,   i.e.  we  scan  STACKSHP{I)    for  1^   I  <^  SHPNUZ 

Given  I,  we  enumerate  the  cargostack,   i.e.  we  scan  srACKCRG(J)     for 

1  £  J  <  CRGC. 

Suppose,   that  given  I  and  J,  say  fcy  calling  ASSNUTL  we  determine  that 
the  pair   is  compatible.     Then:  First,  we  increase  MARK  by  one   (an  extra  arc 
in  graph) .     We  check  bo  see  whether  YES    (J  +  NU)   =  T.     Suppose  it  is  not. 
That  means  that  the  J^^  cargo  has  not  been  found  compatible  to  any  previous 
ship  or  that  this  is  the  first  time  we  scan  cargo  J.     So  we: 
set  YES   (J  +  NU)   =  T  (cargo  is  now  in  graph) 
set  EQUIV   (CAFGOS- IN -GRAPH  +  NU)   =  J    (temporarily, 
node  number     CARGOS- IN -GRAPH  +  NU  corresponds  to  the 
J^  cargo) 

set  BACK    (J  +  NU)    =  CARGOS-IN-ORAPH  +  NU 
We  also  check  the  value  of  YES (I),  and  perform  similar  operations  as 
above.     In  addition,    if  YES (I)   was  F  when  checking,  arc    (I,J)    is  the  first 
arc  starting  fron  ship  I,   so  we  also  set  FIRST   (SHIP-IN-GRAPH)   =  MARK   (ship 
I  will  be  the  SHIPS -IN -GRAPH  th  node) 

Finally,  since  I, J  are  compatible,  ve  also  do: 
HEAD   (MARK)   =  BACK   (J  +  NU)    (set  head  of  new  arc) 
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After  enumerating  all  cargoes,  given  ship  I,  we  check  the  value  of 
YES (I).  If  =  F,  then  we  know  the  ship  I  was  found  incompatible  to  all 
cargoes,  so  it  should  not  be  in  the  grajh  at  all.  On  the  other  hand,  if 
YES  (I)  =  T,  then  ship  I  should  be  connected  to  the  dummy  cargo 
(temporarily  represented  by  node  #  -1) .  So  we  go: 
MARK  =  MARK  +  1      (one  more  arc) 
LAST  (BACK  (I))  =    MARK  (BACK  I  is  the  node  that 

represents  ship  I.  Arc  #  MARK  is  the 
last  arc  starting  from  ship  I) 
HEAD  (MARK)  =  -1 
Once  the  double  loop  (ships  and  cargoes)  is  finished,  the 
contracticn  begins.  First  of  all,  node  0  (the  dummy  ship)  will  be 
connected  cnly  te)  CARGOS- IN -GRAPH  nodes,  not  NV  nodes,  so  we  go 
FIRST  (0)  =  1,  LAST  (0)  =  CARGOS -IN -GRAPH  and  for  1  <  J  <  CARGOS-IN-GRAPHfJ 
(The  lowest  numbers  node  oorrespcnding  to  a  cargo  will  be  node  # 
SHIPS - IN  -GRAPH+1 ) . 
and  EQUIV  (J  +  SHIPS-IN-GRAPH)  =  BQUIV  (J  +  NU) 

This  says  that  the  node  previously  numbered  J  +  NU  is  now  numbered  J 

+  SHIPS-IN-GRAPH  (remember  that  the  EQUIV  array  tells  us  what  cargo  the 

node  represents) . 

Similarily,  BACK  (EQUIV  (J  +  NU)  +  NU)  =  J  +  SHIPS-IN-GRAPH 
An  example  of  the  arrays  before  and  after  the  contraction,  for 

NU=NV=5  will  help  clarify  the  situation  (see  Figure  B.7.3). 

We  must  also  contract  the  HEAD  array  and  reset  the  FIRST  and  LAST 

errays.  To  contract  HEAD,  we  first  note  that  the  number  of  ships  in  the 
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grarh  was  initially  overestimated  by  CORRTERMl  =  W  -SHI  PS -IN -GRAPH.     So, 
if  an  entry  in  the  HEAD  array  is 

=  -1    {d-mtay  cargo)    "^  T    1+  SHIPS-IN-GRAPH  + 

)     CARGO- IN -GRAPH 
it  should  become 


=  -1   (real  cargo)     J 


^    decreased  by  OORRTERM 


In  addition,   the  original  number  of  cargoes  in  the  grajh  was 
overestimated  by  CC«RTERM2  =  NV-CARGOS- IN -GRAPH.     Thus  the  entire  HEAD 
array  should  be  shifted  left  by  C0RRTERM2,   and  similarily,   for 

1  <  I  <  SHIPS-IN-GRAPH,   FIRST    (I)    and  LAST    (I)    should  be  decreased  by  C0RRTERM2. 
An  example,  before  arri  after  the  contraction  is  shown  in  Figure  B.7.4.     The 
reader  may  verify  that  the  graph  in  questioi  is  the  cne  shewn  in  Figure 
B.7.5. 

To  finish  the  contraction,  we  must  set  FIRSr=IiAST=0  for  nodes 
corresponding  to  cargoes,   arri  also  take  care  of  contracting  the  CST  array, 
setting  the  RHS  array  and  a  few  similar  things.  This  will  set  up  the 
network,  which  is  printed  in  a  file  by  writing,   in  the  given  order 
NS{=SHIPS-IN-GRAPH  +  1  =  number  of  sources  in  graph) 
CARGC6-IN-GRAPH     (  =  number  of  sinks) 
NIWARCS   (  =  lAST   (SHIPS-IN-GRAPH)   =  number  of  arcs) 
array  FIRST 
array  LAST 
array  RHS 
array  HEAD 
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array  CST 

Finally,  NErwCXy<  calls  FLOSUB  and  next  POSTOPT. 

The  flowchart  for  NETWORK  is  given  in  a  highly  abbreviated  form,  in 
Figure  B.7.6. 

B.2  SHIFT  Subroutine 

"Parallel"  to  the  cargostack,  we  keep  an  array  of  boolean  entries 
(one  entry  per  cargo  in  the  cargostack) .  After  assignments  and 
deassignments,  the  entries  in  this  array  will  be  T  or  F  cor responding  to 
assigned  or  nonassigned  cargoes  respectively.  SHIFT  looks  only  at  the 
F-cargoes,  and  shifts  all  of  those  to  the  beginning  of  the  stack.  An 
example  is  shown  in  Figure  B.13.1. 

In  addition,  SHIFT  utilizes  two  parameters:  CPGC   and  LAST.  CRGC  is 
the  total  numt>er  of  cargoes  in  the  stack.  The  cargoes  between  LAST+l  and 
CRPC  are  always  automatically  deassigned  (last  portion  of  time  window) . 
Finally,  F-cargoes  are  shifted  only  when  they  have  not  he&n   attempted  to  be 
assigned  more  than  a  fixed  number  of  attempts  (NATTB) . 

B.3  UPD-T  Subroutine 

This  procedure  creates  a  dummy  schedule  for  a  given  ship,  in  order  to 
test  the  utility  of  a  certain  cargo  insertion.  There  are  4  main  pieces  of 
data  involved,  but  before  describing  these,  a  general  overview  is  given. 

Suppose  the  ships  schedule  looks  like  the  one  shown  in  Figure 
B. 14. 1(a),  where  the  S^'s  are  the  stops.  Suppose  we  want  to  insert  the 
pickup  P  of  the  cargo  between  S,  and  S2;  and  the  delivery  D  between  S3  and 
S..  Then  UPD-T  will  first  create  a  schedule  that  looks  like  the  one  shewn 
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in  Figure  B. 14. 1(b). 

Stop  S  and  the  old  schedule  are  not  lost,  rather  the  new  schedule 
is  simulated  by  using  special  pointers  and  the  old  stops. 

The  first  data  structure  is  used  precisely  to  achieve  this.  In  the 
program  it  is  called  NUTORBC  and  consists  of  an  array  of  pointers  of  type 
Link3.  NinORBC(l)  points  to  the  simulated  pickup  (as  above).  In  the 
example  above,  also,  we  have  NOTC»m:(4)  pointing  to  the  simulated  delivery. 

After  the  insertion  of  the  brfo  stops,  some  of  the  data  contained  in 
the  old  stop  records  will  be  incorrect  (with  respect  to  the  simulated 
schedule) ,  for  instance  the  time  data.  Rather  than  change  the  data  in  the 
old  stops  we  keep  2  arrays,  NlJTIME  and  NUSLK,  which  contain  the  updated 
times  and  slacks  for  the  simulated  schedule  (in  both  cases  the  arrays  start 
with  the  new  pickup).  Finally,  array  OUTSLK  contains  the  "future  slacks". 
All  the  arrays  have  COUNT  entries.  In  the  example  above  first  0CUNT=4,  and 
after  inserting  the  delivery,  CCUNT=5. 

There  are  three  routines  that  are  used  by  UPD-T  which  will  not  be 
described  here  in  detail.  They  are  SHIFT  (internal,  not  to  be  confused 
with  procedure  SHIFT,  described  earlier),  TRAVERST  and  SIAXER.  TRAVERSE 
takes  the  original  schedule  of  the  ship  and  generates  the  updated  schedule 
containing  the  pickup  only.  SHIFT  adds  the  delivery  to  the  updated 
schedule.  SLAXER  takes  this  schedule  and  computes  the  array  OJTSLK. 

When  we  insert  the  delivery,  the  variable  PLACE  indicates  where  in 
the  updated  schedule  the  delivery  will  be  (counted  from  the  pickup) .  For 
instance,  in  the  example  above,  PLACE=4.  Before,  a  pointer  of  type  Link3 
points  to  the  stop  before  which  we  are  inserting  the  stop  (whether  pickup 
or  delivery) . 
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As  a  delivered  cargo  is  inserted,  the  old  arrays  containirQ  time 
slack  and  stops  are  preserved  in  arrays  PTIME,  PSLK  and  PTOREC  so  that  they 
can  be  used  for  the  next  delivery  attempt. 
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MORSS 


Start 


READIN 


Reads  in  data  and 
initializes  structures 


DISPLAY 


Displays  data  according 
to  user -driven  menu 


SEEDS 


Performs  seed  assign- 
ments 


DISPLAY 


I 


SCHEDULE 


Main  body  of  MORSS 
algorithm 


DISPLAY 


Figure  B.2 


END 


READIN 
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WHILE 
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IL 
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We  are  dealing  with  Complex  I 


L 


READ  CODE 
NPORTS 


j  We  are  dealing 
.  with  Port  J  in 
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NPORTS 
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FCRG==NIL 
LCRG=NIL 
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NBRTH 

KIND 
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READ  DIST 
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MJMCRG  =  NUMCRG  +  1 


S 


CKtA'i'E  NtW  CARGO  RECORD 


"wm 


ORGCMP 

DESCMP 

ORGPRT 

DESPRT 

EPT,  EDT 

LDT,  SHRTJJ 
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At  Complex  #  ORGCMP 
-  reset  NCRG  =  NCRG+1, 
linked  list  of 
cargo  indices 
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key=nim:rg 

HVYLFT=0 

REMSHR^SHRTN 
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REMSO^SOFT 
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Figure  B.3a 
(A:  continued  in  Fig.  B.3b) 
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NUMSHP  =  NUMSHP  +  1 


CREATE  NEW  SHIP  RECORD 
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array 


*  I-Ol,  user  set,  controls  how  much  output  is  generated  by  MORSS 


Figure  B.3b 
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START 


SEEDS 

When  SEEDS  terminates,  SHIPNO  will  be  the  total  number 
of  ships  in  use 


SET 
SHIPN0=1 
SHPNUZ=0 
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WHILE 
SHIPNO  >  0 
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END 
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IF 
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' 
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SHIPPT  =  Pointer  to  ship  #  SHIPNO 

CR3PPT  =  Pointer  to  cargo  #  CRGNO 

SHPNUZ  =  SHPNUZ+1 

ADD  SHIPNO  to  stack  of  ships 

PCKP  =  NIL 

DET,V  =  NIL 

> 

( 

ASSIGN     cargo  #  CRGNO 

to  ship  #  SHIPNO 

This  procedure  handles  all  the 
assignment  mechanics. 
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Figiore  B.4 
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SCHEDULE 


START 


SET 
CRGC  =  0 
SEEN  ^   0 
STPFLG  =  FALSE 
BANNER  =  FALSE 


REPEAT 

UNTIL 
STPFLG  ^   TRUE 


V 


CRGC  =  #  of  cargoes  in  cargo  stack 

SEEN  =  #  of  cargoes  in  SEEN  so  far 

STPLG  =  flag,  if  true  run  stops 

BANNER  =  becomes  true  v^en  all  cargoes  in  cargo  list  have  been 

downloaded  to  the  cargo  stack  (i.e.,  the  algorithm 

has  "seen"  all  cargoes) 
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RLLTIME 


Sets  up  new  time  windav. 

Returns  (among  others)  i^xiated  values  of 

STACKCRG  (stack  of  cargoes) 

T  (EPT  of  last  cargo  in  time  window) 

CRGC 

SEEN 

BANNER 


I 


IF  CRGC  =  0  and  BANNER  is 
true 

THEN  STPFLG  =  TRUE 


YES 


User  control, 
see  RLLTLME 
description 


Figure  B.S.a 
(A,  B:  cont'd,  in  Figure  B.5.b) 
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B 


u 


IF  CRGC  >  0   and  SHPNUZ  >  0 

THEN 
NETWORK 


Using  cargoes  and  ships  in  current  time 
wisidcM,   sets  up  network,  optimizes  and 
postoptimizes  the  assignment.  Returns: 

FD3WS:  array  of  PRSHP  records,  each 
continuing  assignment  data  for  a 
different  ship. 

TOTAL:   #  of  ships  vdiich  have  been 
assigned  a  cargo. 


END 


IF  TOTAL  >  0  THEN 
PERMASSN 


Attenpts  to  make  permanent  the 
assignments  given  in  array  FLOWS 
returned  by  NETWORK 


L_ 


J 


Figure  B.5.b 
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RLLTIME 


START 


SET 


CRGC2=CRGC 


CRGC=#  of  cargoes  currently  in 

cargo  stack 
CRQC2=  auxiliary  variable,  refer 
to  description  of  SHIFT 


IF  CROC  >  0  THEN 
SHIFT 


Shifts  all  cargo  currently  in  cargo 
stack  to  beginning  of  cargo  stack 


END 


END 


Figure  B.6 


Shift  takes  a  cargo  stack  like 
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ipper  bound  on  latest  EPT  of 
cargoes  in  next  time  window 
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NO 
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#  of  cargoes  in  next 
time  windcw 


DWt^  LOAD 


Puts  cargo  in  the  cargo  stack,  so  that  no 
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APPENDIX  C 

DESCRIPTION  OF    ARGUMENTS  OF  PROGRAMS 

The  following  convention  is  used: 

+  =  input  to  prog ram  and  untouched  by  program 

-  =  created  by  program 

*  =  input  to  program  and  changed  by  program) 

READIN    (VAR  I -01: INTEGER;   VAR  COMPLEX : HUBS; 

VAR  SUPRCMP:ALLAGGC;  VAR  NUMSUP,NIM:RG,NUMSHP:  INTEGER 
VAR  T0-MVT:MVTPTR;   V7VR  SHIPS:BQATPT) 

-I-Ol:  variable  input  by  user  during  execution  of  READIN  and  later  passed 
to  other  programs.     This  variable  is  used  for  output  control.     O  I-Ol 
10.  The  higher  I-Ol  is,   the  more  output   (of  assignment  mechanics, 
etc.)   the  user  will  see. 

-COMPLEX:  array  of  complex  records 

-SUPRO^:   array  of  supercompiex  records 

-NCMSUP,  NIWCRG,  NIWSHP:   numbers  of  supercomplexes,  cargoes  and  ships 

-TO-MVT:  array  of  pointers  to  cargo  records. 

-SHIPS:  array  of  pointers  to  ship  records. 
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SEEDS  (I -01:  INTEGER;  VAR  STACKSHP:  ARRSHP; 

VAR  ODMPLEX:  HLBS;  ^R  SUPRCCMP:  ALIAGC;  V?kR  SHPNUZ:  INTSGE31 
VAR  TO-MVT:  MVTPTR;  VAR  SHIPS :  BQATPT) 

+  I-Ol 

-STACKSHP:  array  created  by  SEEDS  which  contains  the  codes  of  ships  to 

v^iich  cargoes  are  assigned  as  seeds. 
+  OCMPLEX 
+  SUPRCCMP 
-  SHPNUZ:  number  of  ships  to  which  cargoes  are  assigned 

*  TO-MVT:  records  of  seed  cargoes  are  modified 

*  SHIPS:  a  schedule  is  started  for  each  ship  with  a  seed  cargo 
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SCHEDULE  (I -01: INTEGER;  VAR  STACKSHP:  ARRSHP;  VAR  COMPLEX:  HUBS; 

VAR  SUPRCCMP:  ALLAQGC;  VAR  SHPNUZ:  INTEGER;  NUMCR3 : INTEGER 
VAR  TO-MVT:  MUTPTR;  V7^  SHIPS:  BCftTPT) 

+  I -01 
+  STACKSHP 
+  COMPLEX 
+  SUPRCCMP 
+  SHPNUZ 
+  NUMCRG 

*  TD-MVT:  cargo  assignments  will  be  reflected  in  the  cargo  data  structures 

*  SHIPS:  same  as  above,  for  ships. 
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RLLTIME  (I-Ol: INTEGER;  VAR  CRGC,  SEEN,  LIWIT,  NIMCRG,T:  IbTTEGER  VAR  BANNER: 
BOOLEAN;  VAR  STACKCRG:  ARRCR3;  VAR  TRUFLS:  BARRl;  VAR  TO-MVT:  MVTPTR) 

+  I-Ol 

*  CRGC:  number  of  cargoes  in  cargostack  will  generally  increase 

*  SEEIN:  nuinber  of  cargoes  seen  by  algorithm  will  generally  increase. 
+  LIMIT: 

+  NIWCRG: 

*  T   :  user  input. 

*  BANNER:  will  be  set  T  if  we  reach  end   of  cargo  array 

*  STACKCRG 

*  TRUFLS:  this  array  of  boolean  variables  corresponds  to  the  cargo 

stack  they  are  set  to  F  initially,  look  unc3er  POSTOPT) . 
+  TO-MVT: 
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NEIWORK  (I-Ol:  INTEGER;  VAR  STACKCRGrARRCRG;  VAR  STACKSHP:  ARRSHP;  VAR 
CXMPLEX:  HUBS;   VAR  SUPRCOMP:  ALLAGGC;  ^R  CRGC;  SHPNUZ:  INTEGER; 
VAR  AL,BT:  LINKS;  VAR  TO-MVT:MVTPTR;  VAR  SHIPS:  BQATPT;  VAR  FLOWS: 
ALLF;  VMi.   TOTAL:  INTEGER) 

+  I-Ol 

+  STACKCRG:  stack  of  cargoes 

+  STACKSHP:  stack  of  ships 

+  COMPLEX 

+  SUPRCOMP 

+  CRGC,  SHPNUZ:   #  of  cargoes  and  ships  in  their  stacks 

+  AL,BT:   auxiliary  pointers  used  by  ASSNUTIL  to  compute  utilities 

+  TO-MVT:  array  of  all  cargoes 

+  SHIPS:   array  of  all  ships 

-  FLOWS:   variable  of  type  ALLF,  which  itself   is  an  array   {1..N) 

of  PRSHP  records.     Each  PRSHP  record  tells  us  what  was 

assigned  to  a  given  ship.     Each  record  looks  like 

SNm:    integer,   number  of  ship  (in  STACKSHP) 

CNUMS:  array   (1..4)   of  integer,  number  of  cargoes  assigned 

to  ship  (also  in  STACKCFSG) 
PICKS:   array   (1..4)   of  links  of  pointers  to  pickup 

point  in  ship's  schedule,  one  per  assigned  cargo 
DELVS:   as  with  PICKS,   for  delivery  points 
cau^r^:   integer,   total  number  of  cargoes  assigned  to  ship 

-  TOIAL  : total  number  of  ships  to  v^ich  cargoes  were  assigned. 
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PERMASSN    (I-Ol:    INTEX3ER;   VhR  PL,   BT:   LINKS;   VAR  STACKCHG:   ARPC3GR;   VAR 

STACKSHP:   ARE^SHP;   VAR  TRUFLS:   BARRl;   VAR  OJIPLEX:   HUBS;   VAR  SUPRCMP: 
ALLAGGC;  VAR  TO-MVT:      MJTPTR;   mR  SHIPS:   BOATS  VAR  FLCWS:   ALLF;   VhR 
TOIAL:    INTEIGER) 

+  I-Ol 

+AL,  BT:  auxiliary  pointers  utilized  by  ASSNUTIL 

+STACKCRG 

+STACKSHP 

♦TRUFLS:  BARRl  (refer  to  Appendix  A.  Utilized  by 

ASSIGN  ana  later  in  RLLTIME. 
+  CX>1PLEX 
+  SUPRCMP 

*  TO-MVT:  cargo  records  will  be  modified  to  show  assignments 

*  SHIPS:  ship  records  will  be  modified  to  show  assignments 
+  FLOWS:  raw  assignment  data  from  optimizaticxi 

+  TOTAL:  number  of  ships  to  whom  cargoes  have  bean  assigned  in  optimization 
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ASSIGN  (I -01:  INTEGER;  VAR  TOSHP:  LINKS;  VAR  TOCRG: 

LINKS  WiR   BPCKUP;  BDELV:  LINKS;  VPiR  COMPLEX:  HUBS) 

+  I-Ol 

*  TOSHP:  ship's  schedule  is  updated  to  include  stops 

*  BPCKUP:   pointer  to  record  in  ship's  schedule,  before 

which  cargo  pickup  will     occur. 
*BDELV:  as  BPCKUP,   for  delivery 
+  COMPLEX 
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UPD-P  (I -01:  INTEGER;  DELIVERY:  BOOLEAN;  VAR  TOSHP:  LINKS; 

VAR   TOCRG:  LINKl;  VAR  BEFORE,  PMVT:  LINKS;  VAR  COMPLEX:  HD 

+  I-Ol 

*  EEIilVERY:  =  T  if  stop  to  be  inserted   is  a  delivery 

*  TOSHP:  ship's  schedule   is  modified 

*  100*3:  cargo's  pickup  list  modified 

+  BEEXDRE:   pointer   to  stop  iirenediately  following  insertion 
-PMVT:   pointer  to  inserted  stop  (manufactured  by  UPD-P) 
+  OCMPLEX 


-174- 


DWN-LQ?UD    (I-Ol:    INTEGER;   VAR  STACKCRG:   ARRCRG;   V7^  CRGC,   SEEN:    INTEGER; 

LIMIT,  NCRG,  T:  INTEGER;  VAR  IRUFLS:  BARRl;  VAR  BANNER:  BOOLEAN;  VAR 
TO-MVT:  MTTPTR) 

+  I-Ol 

*  STACKCRG:  new  cargoes  are  generally  down  loaded  onto  stack. 

*  CRGC:  cargo  count  =  number  of  cargoes  in  stack. 

*  SEIEN:  number  of  cargoes  that  have  been  scanned  in  overall  list. 

+  LIMIT:  up^r  bound  on  number  of  cargoes  in  stack  (=  time  window). 

+  NCRG:  total  number  of  cargoes  in  overall  list. 

+  T  :  upper  bound  on  EPT's  in  time  window  being  built. 

*  TRUFLS:  this  array  utilized  in  SHIFT,  page 

*  BANNER:  becomes  TF3JE  if  we  reach  end  of  overall  cargo  list. 
+  TO-MVT 
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QUPD  (I-Ol:  INIBGER;  VAR  PCKUP,  DELU:  LINKS;  VAR  TOSHP:  LINKS;  VAR  T0CR3: 
LINKl) 

+  I-Ol 

*  PCKUP:   pointer  to  pickup  record.  Record  changed  to  reflect 

quantity  picked  up. 
DELV:   pointer  to  delivery  record.  Record  changed  to  reflect 

quantity  delivered. 
*TOSHP:    pointer  to  ship.  Ship's  schedule  changed    (capacities  reduced). 

*  TOCRG:   pointer  to  cargo. 
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SHIPr  (I-Ol:  INTEGER;  VAR  STACKCRG:  ARRCRG;  VAR  THJFLS: 

BARRl;  \^^  CRGC,  LAST:  INTBGER,  V7^  TO-MVT:  MVTPTR) 

+  I-Ol 

*  STACKCRG:  ADTIMPT  will  be  increased  by  1  for  some  cargoes 

*  TRDFLS:  Remaining  cargoes  will  be  mac3e  into  F's 

*  CRGC:  Updated 
+  lAST 

*  TO-MVT 
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UPD-T  (I -01:  INTEGER;  DELIVERY:  BOOLEAN;  VAR  CCUNT: 

INTEGER;  VP^  AL,  BET:  LINK3;  VAR  NUTIME,  DTIME, 
NUSLK,  PSLK,  OJTSLK:  ARSHP;  VAR  TCKEC,  PT(»BC:  PARRZ; 
VAR  TD-MVT:  MVTPTR;  \;AR  COMPLEX:  HUBS) 

+1-01 

+DELIVERY:  BOOLEAN,  =  T  if  inserting  delivery 

*  COUNT:  length  of  attempted  schedule  as  measured  from  pickup 

*  AL,BET:  auxiliary  pointers,  used  to  store  pickup  and  delivery 

*  NUTIME,... ,OUTSLK:  arrays  to  hold  time  and  slack  data 
*TQRBC,  PTOREC:  arrays  to  hold  stop  pointers  for  schedule 
+  TO-MVT 

+  COMPLEX 


/6'-a2>- 


MIT   LI8HAHIES 


3    TOAD    DDD    17b    fl31 


^pm 


APR  04 1B91 


Lib-26-67 


|;^r     aod^     (5     On    i^o^cLk   cu)\l^>r 


